[Mono-dev] Type.GUID patch

[Kornél Pál]

Hi,

Type.GUID is useful only when using COM interop. Of course there may be
other uses but I don't tink it is needed for anything else.

GUIDs are identifiers in COM so I think we should not implement a different
algorythm just to return some value. I think it's better to throw an
exception for type that have no GuidAttribute instead of returning some
forged value that is different from MS.NET type GUID.

I think performance is not so important regarding this property as it is
called rarely. But if we want to speed up GUID property it can be cached in
a private field.

Kornél

----- Original Message -----
From: "Sebastien Pouliot" <sebastien.pouliot at gmail.com>
To: "Robert Jordan" <robertj at gmx.net>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Saturday, September 03, 2005 7:09 PM
Subject: Re: [Mono-dev] Type.GUID patch


> Hello Robert,
>
> On Sat, 2005-03-09 at 17:00 +0200, Robert Jordan wrote:
>> The hash appears to change with the assembly name and type name.
>> Renaming gt.cs will return another GUID as well as renaming
>> "App". Renaming gt.exe doesn't change the GUID.
>> Applying an AssemblyVersionAttribute will change the GUID,
>> so I'm pretty sure, that Type.AssemblyQualifiedName is taken
>> into account while generating the hash.
>>
>> The following algorithm computes the GUID from
>> Type.AssemblyQualifiedName using a MD5 hash:
>>
>> Guid ComputeGuid (Type t)
>> {
>>      byte[] bytes = System.Text.Encoding.UTF8.
>>          GetBytes (t.AssemblyQualifiedName);
>>      using (System.Security.Cryptography.MD5 md5 =
>>             System.Security.Cryptography.MD5.Create ()) {
>>          return new Guid (md5.ComputeHash (bytes));
>>      }
>> }
>>
>> Is it a patch worth?
>
> I guess it depends on how it's gonna be used. This isn't the first time
> people talks about Type.Guid but I never seen any talk about _using_
> it ;-) at least not with Mono.
>
> MD5 will give you a 128 bits digest value, which match the required Guid
> length, and recent problems related to MD5 are pretty much irrelevant to
> such usage. So it's probably (if everything is included in the qualified
> name) a correct implementation - functionality-wise.
>
> But creating a using MD5 is kind of heavyweight - even more if a new
> instance is created each time. So anyone using this heavily will notice
> a big performance problem.
> --
> Sebastien Pouliot
> email: sebastien at ximian.com
> blog: http://pages.infinit.net/ctech/
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>