[Mono-devel-list] IKVM show stopper

Paolo Molaro lupus at ximian.com
Fri Jun 11 05:28:40 EDT 2004

On 06/11/04 Jeroen Frijters wrote:
> Thanks! At the moment methods and ctors are all I need, but I think I'll
> need fields as well in the future (once I fix my field reflection code),
> but this isn't as critical because field names are rarely overloaded. I
> don't need any other tokens though.


> > Yes. Do you rely on that behaviour?
> No. It was just something I noticed. My understanding is that they are
> supposed to match, but I certainly don't need it.

Since it's not always possible to make them match I didn't bother with
the effort to make them match in some more cases than now.

> > (it's easier since we keep separate arrays for ctors and 
> > normal methods).
> > In the general case the tokens won't match, because the methods of a
> > type need to be contiguous in the PE file, but with reflection you can
> > create a few mthods for a type, then for another, then for the old one
> > again and the tokesn are assigned sequentially.
> I don't know anything about the PE format, so this might be a lame
> suggestion, but can't you simply write them out in token order when the
> assembly is saved?

Yes, we might do this if some application happens to depend on this
internal implementation detail of the MS runtime. It still is not
possible in the general case to have the tokens match, so people should
be discouraged from depending on this behaviour.
In the above scenario, if we create 2 methods in type A and then a
method in type B and again a method in type A, the tokens at runtime
will be:
	0x6000001 A:method1()
	0x6000002 A:method2()
	0x6000003 B:method1()
	0x6000004 A:method3()

But since in the PE file format the methods of a type must be
contiguous, in the PE file the tokens will be:
	0x6000001 A:method1()
	0x6000002 A:method2()
	0x6000003 A:method3()
	0x6000004 B:method1()


lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better

More information about the Mono-devel-list mailing list