[Mono-dev] [PATCH] Improve compiler generated class handling and ReferenceEquality comparer.

Kornél Pál kornelpal at gmail.com
Tue Mar 2 05:20:56 EST 2010


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


More information about the Mono-devel-list mailing list