[DotGNU]Re: [Mono-list] Enum declaration; Conflicts and Blame for Interoperability Problems

[Paolo Molaro]

On 01/07/03 Marcus wrote:
> My reason for posting this is two-fold. I have a specific problem with 
> compatibility between Mono and Pnet, and I want to point out that situations 
> like this are not a unusual occurrence.

Thanks, you're helping fix issues in both projects.

> The problem occurred as part of my testing to assess how well Qt# 
> interoperates with Mono and Pnet. I discovered that when classes containing 
> enums were compiled into libraries by the Mono C# Compiler (mcs), Pnet's C# 
> Compiler (cscc) did not handle the enum's member properly. Specifically, with 
> a declaration like this
> 
> class QFont {
> public enum Weight { Light = 25, Normal = 50, DemiBold = 63, Bold = 75, Black 
> = 87 } }
> 
> Pnet believed that the type of QFont.Weight.Bold was "int" instead of 
> "QFont.Weight". The problem came down to the fact that cscc was expecting 
> enums to be declared the way that csc and the examples in ECMA 335 do:
[...]

On 01/07/03 Rhys Weatherley wrote:
> > The problem now is that the Mono developers claim that their
> > declaration is correct and in compliance with the spec, whereas the Pnet
> > are equally adamant that Mono is wrong and that Mono should fix their C#
> > compiler.
> 
> *ahem* Not to start a spec interpretation war or anything (as I've already 
> worked around this):
> 
> Section 7.5.4 of ECMA-335, page 34:
> 
>     CLS Rule 9: Literal static fields (see clause 7.6.1) of an enum shall
>     have the type of the enum itself.

Paragraph 13.3 in Partition II says basically the same things, but adds
soon after:

For binding purposes (e.g. for locating a method definition from the
method reference used to call it) enums 
shall be distinct from their underlying type.  For all other purposes,
                                               ^^^^^^^^^^^^^^^^^^^^^^
including verification and execution of 
code, an unboxed enum freely interconverts with its underlying type.

We think this sentence allows the use of the underlying type instead of
the enum type in the static fields of the enum.
The underlying issue, though, is that with the Reflection.Emit API it's
not possible to create enums as produced by csc. Once portable.net
will implement Reflection.Emit, it'll have to support this stuff anyway,
just like the MS runtime does.

> > I honestly do not know who is right or wrong in this situation.
> 
> Since it is easy for cscc to deal with both forms, just as Rotor does, it 
> isn't really a case of right or wrong for us, but handling odd boundary cases 
> in a rational manner.  Cscc itself will continue to generate the enum-typed 
> version for fields, just as csc and Rotor do.

Generating the fields with the enum type is better, if it's at all
possible (better mostly in the sense: better looking:-). The metadata 
loader needs to be able to deal with the interconversion from the enum 
type and the underlying type, though.

Cheers.

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better
_______________________________________________
Developers mailing list
Developers@dotgnu.org
http://www.dotgnu.org/mailman/listinfo/developers