Hi Marek, >> Although currently only a single compiler generated class benefits >> from both of these modifications I don't see any drawbacks and in my >> opinion the changes result in a more properly designed compiler >> generated class infrastructure. > I am not sure what does "more properly designed compiler generated class > infrastructure" mean but removing sealed from other generated classes > it's not. The fix should be to add a new overload to avoid clearing the > sealed flag.
Since the constructor accepts a "Modifiers mod" parameter adding another (for example bool) parameter that would affect the Modifiers parameter sounds too complicated to me. On more properly designed I mean that I belive that a class being comipler generated doesn't imply that it also has to be sealed, furthermore it also can be either sealed or static, and there is no need for enforcing any of them because the constructor accepts Modifiers. (Similarly it does not enforce any visibility flags either.) In my opinion adding Modifiers.COMPILER_GENERATED on the other hand is the expected behavior. CompilerGeneratedClass currently has three child classes: AnonymousMethodStorey: Currently relies on Modifiers.SEALED being added by the base class constructor and modified to pass Modifiers.SEALED to the base constructor in the patch. AnonymousTypeClass: Already passes Modifiers.SEALED to the base constructor. DynamicExpressionStatement.StaticDataClass: Passes Modifiers.STATIC to the base constructor and without the patch has to remove Modifiers.SEALED in its constructor body Kornel _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list