Kornél Pál wrote: > mcs creates an assembly, then creates types, and only after that is > processing the custom attributes. This is how attributes and even > assembly name (not the name part) can change after definition. Although > there are some other self referencing cases, this order of > creation/definition is required especially when building mscorlib.dll.
OK, that makes sense. I skipped custom attributes in my mcs IKVM.Reflection hack, so that may account for not running into that. I don't really like AssemblyBuilder.__SetName(), however. How about adding __SetVersion(), __SetCulture() and __SetKeyPair()? > Blob encoded pseudo custom attributes are supported by Mono. I've added > decoding because they weren't ignored, exceptions were thrown instead. Yes, I'll fix the code not to throw exceptions, but silently ignore them (like .NET does). > Unlike Java, C# has support for backward jumps, so does > System.Reflection.Emit so support for that will have to be implemented. The "backwards branch constraint" is an ECMA CIL restriction. The Microsoft CLR supports code that violates it, but years ago when I first found out about this it was because ikvm generated code that violated it and Mono didn't support that. So, I don't think it is necessary to support this (as it isn't valid ECMA CIL anyway). If mcs generates code that triggers this exception, then it is a bug in ILGenerator, or a bug in mcs. > Based on your questions I belive that you are trying to remain > compatible with MS.NET. Yes. However, I'm all for adding extra functionality (either by __ methods or by having ___ settings to enable/disable specific behavior). > I on the other hand belive that removing arbitrary limitations of > System.Reflection.Emit (like preventing access to TypeBuilder's member- > builders), and adding missing functionality would make sense. I agree, but I don't want to create a situation where you unintentionally depend on an IKVM.Reflection specific feature. Based on your work I have identified a couple of cases where things can be improved (e.g. I agree that the __GetDeclaredXxx methods should expose unbaked members in TypeBuilders). > I also like the concept of having a Universe since that makes possible > to have multiple compiler instances in the same AppDomain. Yes, I made the mistake in ikvm/ikvmc to have lots of statics and didn't want to make that mistake again ;-) > I belive that pseudo custom attributes and unmanaged resource generation > does not fit well to the concept of System.Reflection.Emit. I kind of agree. I will add a mode to disable them and add specific __ methods to do the equivalent. > I also belive that CustomAttributeData should not be used as a provider, > __GetCustomAttributes (non-standard since is returning constructor > arguments rather than class instance) methods should be added to > reflection classes. An ICustomAttributeProvider interface (with > IsDefined and __GetCustomAttributes methods) would be very useful as > well. Agreed. Regards, Jeroen _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
