[Mono-dev] New Mono API status pages.

[Gert Driesen]

> -----Original Message-----
> From: mono-devel-list-bounces at lists.ximian.com
[mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Miguel de
Icaza
> Sent: zaterdag 11 april 2009 18:56
> To: Gert Driesen
> Cc: 'Eyal Alaluf'; 'mono-devel-list'
> Subject: Re: [Mono-dev] New Mono API status pages.
>
> Hello Gert,
>
> > I noticed a few important differences compared to the old status  
> > pages:
>
> The web UI is using the same engine now that gui-compare in mono-tools  
> is using.
>
> The old status pages had not been maintained for months and stopped  
> being updated for months before someone noticed.

People did notice, but that's not relevant anymore.
I definitely prefer the way the new status pages are built, but the
information they list is not yet up to the same level.
Two examples:
* (some) type attribute mismatches are ignored (eg. difference in
layout/charset for System.Drawing.Color)
* support for (listing extra/missing) explicit interface implementations has
also been removed/commented out (if I'm not mistaken)

> > * there's no additional information for warnings
>
> I thought I got most of these, can you point to specific cases that  
> are missing information?

One example are the warnings on AllowEdit/AllowNew for System.Data.DataView
(Mono 3.5 vs. .NET 3.5).
I don't see where we throw NIE here, and there's no explanation for the
warning icons.

Another example is System.Data.DataSet (Mono 3.5 vs. .NET 3.5), for which
there's a warning listed without any explanation.

>
> > * all members that throw a NotImplementedException are considered as  
> > error
> > while in some cases this is actually the intended behavior (which also
> > matches MS)
>
> This is hard to fix without a white list and was never supported in  
> the old pages.

I know but the old status pages did not check IL for NIEs; they used the
presence of MonoTODO (and related) custom attribute to detect incomplete or
missing implementations. I actually prefer this approach.

> > * argument name mismatches are no longer reported (this will become  
> > more
> > important as C# 4.0 now supports named parameters too)
>
> Yeah, in the future we will add a new option (just like we now have  
> two modes of comparison) to sort this out.

OK, great.

Gert