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

[Paolo Molaro]

On 01/07/03 Gopal V wrote:
> > Paragraph 13.3 in Partition II says basically the same things, but adds
> > soon after:
> > 
> > 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.
> > 
> .....
> > will implement Reflection.Emit, it'll have to support this stuff anyway,
> > just like the MS runtime does.
> 
> So this is like saying Reflection.Emit API is to blame here ?. I wonder
> what output MCS running on MS .NET would give ... (would it be the same ?).

Running mcs with the ms runtime produces the same output as with the
mono runtime (but a few bugs that we fixed in our version of
reflection.emit).

> Hmm... since CSCC does not use Reflection.Emit, I think we'll not be affected
> by this bug at all ... and field boxing has already been added for resolving

It is not a bug.
_If_ the issue is an API issue with Reflection.Emit you'll be affected as
well when you'll implement it, the fact that cscc doesn't use Reflection
doesn't matter one bit. Unless, of course, you implement a different
API.

> I don't like the idea of complicating the image loading routines and 
> modifying at load time. The runtime doesn't have any huge issues as 

Rhys said he already fixed it for pnet.

> I think Qt# is digging up quite a few bugs ... (and some "virtual" bugs,
> like this one).. It looks like Reflection.Emit API isn't as hot as they 
> were made up to be ...

It looks like this was an issue in pnet, just like the PropertyMap one, 
so please take the flame bait somewhere else.

lupus

-- 
-----------------------------------------------------------------
address@hidden                                     debian/rules
address@hidden                             Monkeys do it better