2011-09-20 4 views
10

In diversi punti (ad esempio "Creating Windows Runtime Components for JavaScript, in C# and Visual Basic" su MSDN), ho visto che ha specificato che, se si scrive una classe in .NET che si desidera utilizzare da JavaScript, è necessario renderla una classe sigillata.Perché i tipi WinRT devono essere sigillati?

Questa sembra una restrizione arbitraria. Perché JavaScript può funzionare solo con classi sigillate?

+6

Poiché WinRT è basato su COM e COM non supporta l'ereditarietà. La parola chiave * sealed * assicura che sia chiaro a tutti coloro che vedono il codice che tale classe non è estendibile attraverso l'ereditarietà. –

+1

@Hans In realtà c'è qualche forma di ereditarietà supportata da WinRT stesso - ad es. puoi ereditare da 'FrameworkElement' (che è esso stesso una classe WinRT) in .NET. E non devi contrassegnare le classi definite in C++/CX come sigillate e puoi anche ereditarle. Quindi questa sembra essere una limitazione solo per autorizzare i componenti WinRT in .NET, non una limitazione (ereditata dal COM) di WinRT stesso. –

+4

@Hans: COM supporta l'ereditarietà. Tuttavia non permettiamo l'ereditarietà dell'interfaccia nelle interfacce winrt. –

risposta

7

Gli oggetti di runtime di Windows esposti alle applicazioni JavaScript sono sigillati da una prospettiva JavaScript - non è possibile aggiungere le proprietà expando agli oggetti WinRT. Ma da C++ e C#, gli oggetti winrt possono essere ereditati se l'oggetto supporta l'ereditarietà (la maggior parte delle classi Xaml supporta l'ereditarietà per esempio, ma molti altri non lo fanno).

Il motivo per cui gli oggetti WinRT sono sigillati da JS è quello di garantire che l'oggetto winrt si comporti allo stesso modo indipendentemente da ciò che ha fatto l'app - se un'app ridefinisce alcune proprietà di funzione su un oggetto, potrebbe causare altre parti dell'app comportarsi male.

+0

Stessa limitazione per C#, controllare a 40:15 in questo video: http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-531T COM non supporta l'ereditarietà dell'implementazione. –

+2

@Hans: questo non ha assolutamente nulla a che fare con COM. Il runtime di Windows è * non * COM (ha alcuni elementi di COM, ma è * molto * diverso). Il runtime supporta l'ereditarietà: come già detto in precedenza, Pavel può derivare da FrameWorkElement in C++/CX o C#/VB. –

+2

Non posso fare a meno di fare "il provino da IUnknown, fa riferimento al conteggio: deve essere anatra". In attesa di voi blogging su questo. –