[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DotGNU]Re: [Mono-list] Enum declaration; Conflicts and Blame for In
Re: [DotGNU]Re: [Mono-list] Enum declaration; Conflicts and Blame for Interoperability Problems
Tue, 7 Jan 2003 19:12:28 +0100
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
> 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
> 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.
address@hidden Monkeys do it better