In the previous post I retraced the motivations that led to WinRT.
One of the fundamental requirements of WinRT is to allow better interaction between different languages, either native or managed. We also have already seen that only a runtime that exposes functionality in an object oriented fashion can provide a clean and simple interoperability.
Interoperability between WinRT and programming languages is settled by "projections" that solve two problems:
The first step was therefore to establish a type system.
There is a new String type whose binary representation avoids marshalling operations with wstring (C++) or with Framework.NET string. The new String is immutable as it is in Framework.NET but instead of being a reference type, WinRT string is a value type as it happens for wstring and therefore non-nullable. This allows you to smooth out the differences between various languages. In order to build strings C++ developers use wstring or wstringstream while VB/c # will continue to use StringBuilder as always.
Reference type. WinRT describes the objects layout using interfaces, therefore all objects that implement interfaces are reference types. As a consequence, when calling a function, object parameters are passed by reference, while the rest are passed by value. Furthermore parameters are passed as [in] or [out] and never in [in, out].
Value type. According to the previous definition of reference types, value types are "the rest". Arrays are value type (unlike Framework.NET) and structures cannot hold pointers/references in order to avoid the problems related to the cost when copying structures (deep vs. shallow copy problem).
Among the various other types defined in the namespace "Platform", there are Vector and Map that maps to collections and dictionaries of the .NET Framework. Note that Vector<T> implements IObservableVector<T> and then natively supports change notifications.
Obviously there are booleans, enums and many other basic types as Object, Type, and Guid, but I could not find anything different than what I expected: they are simply natural types.
It is clear that each language offer peculiarities that cannot be ignored. This was a problem during .NET Framework design (see CLSCompliant attribute) and continues to be in WinRT.
Rather the fact that now there is a standard way a language can be interfaced to WinRT opens the intriguing scenario of third-party languages. At this point seems a step obvious for Java, Python, Ruby, D, Delphi, and who knows how many others.
Privacy | Legal Copyright © Raffaele Rialdi 2009, Senior Software Developer, Consultant, p.iva IT01741850992, hosted by Vevy Europe Advanced Technologies Division. Site created by Raffaele Rialdi, 2009 - 2015 Hosted by: © 2008-2015 Vevy Europe S.p.A. - via Semeria, 16A - 16131 Genova - Italia - P.IVA 00269300109