[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