[Mono-dev] [Patch] AssemblyName ctor

Kornél Pál kornelpal at hotmail.com
Mon Aug 22 15:10:56 EDT 2005


I gave you some hints about the code but I did not think about the purpose
of the code. In other words: Do we need it?

And I think not. I know you have work in the patch but it is better to have
a single code to parse assembly names. This code has to be unmanaged as
assembly names has to be parsed inside the runtime before any assembly could
be executed. Having a managed one as well makes things more difficult as
both of them has to be maintained and there is little chance to provide
exactly the same functionality by both of them. And it is worse than
creating an extra MonoAssemblyName instance.

If you want to avoid unnecessary code to be executed you should modify the
unmanaged assembly name parser method.


----- Original Message -----
From: "Carlos Alberto Cortez" <calberto.cortez at gmail.com>
To: "Paolo Molaro" <lupus at ximian.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Monday, August 22, 2005 6:22 PM
Subject: Re: [Mono-dev] [Patch] AssemblyName ctor

> Hey Paolo,
> We have mono_assembly_name_parse, which receives a MonoString* and a
> MonoAssemblyName*. The problem I find is that every time a
> System.Reflection.AssemblyName were created using the described ctor, we
> should also create a MonoAssemblyName (not needed).
> With the managed ctor, we also avoid calling the internal call.
> What do you think?
> Carlos.
> El sáb, 20-08-2005 a las 12:27 +0200, Paolo Molaro escribió:
>> On 08/19/05 Carlos Alberto Cortez wrote:
>> > The patch attached implements the new AssemblyName ctor without using
>> > internal calls. Could anybody review it?
>> And the advantage of this is?
>> The runtime needs and does have a function to do the parsing of the
>> string, so just use an icall to use that.
>> lupus
> _______________________________________________
> 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