[Mono-devel-list] [PATCH] Profile 2.0 assembly versions

Andreas Nahr ClassDevelopment at A-SoftTech.com
Thu Jul 28 18:42:51 EDT 2005


Yes - it would make a lot of sense to put them into a single file. However 
it would come at a cost of up to 2kb of size added to EACH assembly that 
uses Consts.

In fact I think we could do something really clever to our compiler here, 
that would also benefit for a lot of other cases.
AFAIK the compiler can already eliminate dead code. I would propose a step 
that allows the compiler to scan for dead code again AFTER constants are 
resolved. This way the compiler would be able to completely eliminate the 
Consts Class after compiling. This would also add lots of added value to 
other applications. It's quite common to use private consts and especially 
enums to structure the code and make it more readable. With the proposed 
compiler function all of these things could be thrown out at compile-time, 
which could help a lot of applications to get smaller.

We could add a compiler-switch for that like -EliminatePrivateConstants

Andreas

----- Original Message ----- 
From: "Ben Maurer" <bmaurer at ximian.com>
To: "Andreas Nahr" <ClassDevelopment at A-SoftTech.com>
Cc: "Kornél Pál" <kornelpal at hotmail.com>; "Miguel de Icaza" 
<miguel at ximian.com>; <mono-devel-list at lists.ximian.com>
Sent: Friday, July 29, 2005 12:11 AM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions


> On Fri, 2005-07-29 at 00:07 +0200, Andreas Nahr wrote:
>> No Consts.cs aren't automatically generated.
>> The problem is, that several Attributes of classes in System.Web do not 
>> use
>> the consts scheme, and about one third of your (BIG) patch is just for
>> changing these Attributes.
>> We will then have to change these again later, so it might make sense do 
>> do
>> it now instead of doing it twice (and adding lots of changelog entries
>> twice).
>
> If we really want to be clever, and avoid doing things twice, we can put
> this:
>
> internal class MonoConsts {
> #if ...
> public string FXVersion = ...
> #elif ...
> ...
> #endif
> }
>
> in the common build directory. This way, the next time we need to target
> another FX, we don't have to do it in 100 places.
>
> The Const.cs is probably still a good idea, since it is really ugly to
> have those magic names lying around the source code.
>
> -- Ben
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 




More information about the Mono-devel-list mailing list