[Mono-list] Implementing ECMA CLI vs Microsoft's .NET Framework

[Peter Drayton]

Sam Ruby <rubys@us.ibm.com> wrote:
> You might find it productive to spend a few minutes reading 
> the first three pages of Partition IV.
> (http://msdn.microsoft.com/net/ecma/Partition_IV_Library.pdf).
> In short, the CLI contains a number of profiles, and a conforming 
> implementation need not implement all of them (for example: a PDA 
> may not have floating point). Adding a profile can involve adding 
> methods to an preexisting class.

Understood. I can honestly say that I'd already read that prose a bunch
of times before posting :-). I've always found the relationship between
Profiles and Libraries interesting, especially the fact that adding
Library X, can change the signature of a method in a Library Y and add
interfaces to types in Library Z. However, since the spec calls for a
CLI implemention to declare what profile and additional libraries it
supports, would it be fair then to say Mono is implementing the Compact
profile, as well as the Floating Point, Extended Array and <insert the
rest of .NET> libraries? :-) 

> Another thing to contemplate - what is being standardized at this time
in
> ECMA TC39 represents our best guess on what is a reasonable core.
Only
> real life experience will validate how well we do.  An independent
> implementation (or three!) would provide either a extremely valuable
> validation of this, or extremely valuable input as to what should be
added
> in the next cycle.

Reasonable core what? The original submission included a lot more types
(IIRC some 500-odd extra over the ~250 currently included), but even
that didn't cover things like ASP.NET, ADO.NET, WinForms, WebForms, etc.
My understanding was that the current set of types in the CLI would grow
over time, but that the end goal was closer to the original submission
than the whole of Microsoft's .NET framwork. Do you mean that ECMA/TC39
might end up standardizing all of the ~3000-4000 types in Microsoft's
.NET Framework? 

AFAICT Mono seems to be shooting for a complete .NET clone (which is
cool), but I don't see how the efforts to add the rest of .NET (ASP.NET,
ADO.NET, WinForms, etc.) help you validate the CLI specs, even
accounting for the CLI growing over time. It seems to me that when
issues come up like "the .NET docs say this type has 3 constructors, the
ECMA specs only have 2, what do I implement?", a implementation that was
trying to validate the spec would prefer to implement the 2 ECMA ctors,
and if it turned out all 3 were needed, then that would identify a place
to enhance the spec. By cloning .NET, rather than implementing the spec,
this might never be detected and the specs wouldn't improve. 

> A final thought - if you look at JDK documentation, you will see
> annotations such as "introduced in JDK 1.2".  One thing that (IMHO)
opinion
> would be extremely valuable is a proposal for a standard set of
metadata
> which enables the one to determine what profile a given method belongs
to,
> and what version of that profile.  This would enable compilers to
provide
> warnings (e.g., this code contains references to floating point - and
may
> not run on compact devices).  Such a proposal would have to be
cognizant of
> the potential footprint and runtime overhead associated with such
metadata.

100% Agreed - I like this idea *a lot* (I presume you meant library, not
profile, correct?). Additionally, it seems that you'd need to go beyond
just methods and also attribute types, interfaces, the 'throws list',
etc. with this information.

Were you thinking of using CAs, or rather direct metadata
representation? I don't see anything in partition IV that precludes
implementing this as custom attributes, though it does state "...there
need not be any direct support for Libraries and Profiles in the VES;
they are not represented in the metadata". Implementing this with CAs
seems consistent with the way CLS compliance is asserted using CAs.

--Peter
http://staff.develop.com/peterd