Ah, agreed. We have had the same conversation internally and we are definitely concerned about the parity between API's. Can't say exactly how far we will get in that respect right now, but (I believe it was Miguel from Ximian that made the suggestion) we are taking that suggestion seriously.
Just for the record, you actually brought up two important points: 1) That the reflection (browsing) and reflection emit (code creation) API's should be symmetrical and complete. 2) That we shouldn't have discriminatory C#'isms or C#/CLS policy in reflection where it's not warranted. Again, I can't commit to specific work items, but I can say that we care about both of these. Thanks, Chris Christopher Brown Program Manager Common Language Runtime -----Original Message----- From: Jeroen Frijters [mailto:[EMAIL PROTECTED]] Sent: Monday, August 19, 2002 12:50 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET-ROTOR] sbyte[] == byte[] Someone from Ximiam (the company leading the Mono effort) joked (or may be not!) that ILASM should be rewritten using Reflection (.Emit). If that were possible that would be great. The current reflection API has many CLS and C#-isms. Not being able to interchange sbyte[] and byte[] is just one example. BTW, I found another bug in the C# compiler: enum MyEnum {} class enumtest { public static void Main() { // following line doesn't compile System.IComparable c = new MyEnum(); } } Regards, Jeroen > -----Original Message----- > From: Discussion of the Rotor Shared Source CLI > implementation [mailto:[EMAIL PROTECTED]] On > Behalf Of Christopher Brown (NDP) > Sent: Monday, August 19, 2002 20:31 > To: [EMAIL PROTECTED] > Subject: Re: [DOTNET-ROTOR] sbyte[] == byte[] > > > What 'equivalence' would you expect from reflection? There may be > instances where reflection policy is too stringent and we > should take a > look at them. > > Thanks, > Chris > > > -----Original Message----- > From: Jeroen Frijters [mailto:[EMAIL PROTECTED]] > Sent: Sunday, August 18, 2002 11:40 PM > To: [EMAIL PROTECTED] > Subject: Re: [DOTNET-ROTOR] sbyte[] == byte[] > > Thanks, that's what I was looking for. I like this behaviour, but it > does trigger a second question. Why doesn't Reflection allow the same > "type equivalence"? > > Regards, > Jeroen > > > -----Original Message----- > > From: Discussion of the Rotor Shared Source CLI > > implementation [mailto:[EMAIL PROTECTED]] On > > Behalf Of David Stutz > > Sent: Monday, August 19, 2002 04:11 > > To: [EMAIL PROTECTED] > > Subject: Re: [DOTNET-ROTOR] sbyte[] == byte[] > > > > > > Section 1.8.1.2 of Partition 3 talks about the "verification type > > system." As Peter points out, for verification, the number of > > types can > > be drastically reduced. Take a look at this section of the > spec for a > > fairly rigorous explanation. > > > > -----Original Message----- > > From: Peter Drayton [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, August 18, 2002 11:32 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [DOTNET-ROTOR] sbyte[] == byte[] > > > > > > I think this is by design - there's really little difference > > between the > > signed and unsigned versions of the short data types, except how the > > bits are interpreted. Assigning a value >127 to an int8 simply > > overflows. See example [1] below. Arrays of type "unsigned > int8[]" are > > assignment-compatible with arrays of type "int8[]" (see example [2] > > below), which supports this theory. > > > > On a quick troll of the ECMA specs I couldn't find the > exact spot that > > asserts this, though there are numerous references to unsigned being > > merely an alternate form of signed, and interpreted based > on modifers > > (unsigned) and special opcodes (e.g. *.ovf). > > > > --Peter > > http://www.razorsoft.net/weblog > > http://staff.develop.com/peterd > > > > [1] > > assembly extern mscorlib {} > > .assembly overflow {} > > .method static void main() { > > .entrypoint > > .locals init (unsigned int8 b, int8 sb) > > ldc.i4 128 > > stloc b > > ldloc b > > stloc sb > > ldloc sb > > box [mscorlib]System.SByte > > call void [mscorlib]System.Console::WriteLine(object) > > ldloc b > > box [mscorlib]System.Byte > > call void [mscorlib]System.Console::WriteLine(object) > > ret > > } > > > > [2] > > .assembly extern mscorlib {} > > .assembly overflow {} > > .method static void main() { > > .entrypoint > > .locals init (unsigned int8[] rgb, int8[] rgsb) > > ldc.i4 1 > > newarr unsigned int8 > > dup > > stloc rgsb > > stloc rgb > > ret > > } > > > > > -----Original Message----- > > > From: Discussion of the Rotor Shared Source CLI implementation > > > [mailto:[EMAIL PROTECTED]] On Behalf Of > > Jeroen Frijters > > > Sent: Saturday, August 17, 2002 11:43 AM > > > To: [EMAIL PROTECTED] > > > Subject: [DOTNET-ROTOR] sbyte[] == byte[] > > > > > > > > > When I call a method expecting a byte[] with an sbyte[], > > the verifier > > > doesn't mind. Is this by design or is it a bug? > > > > > > .assembly extern mscorlib {} > > > .assembly test {} > > > .module test.exe > > > .imagebase 0x00400000 > > > .subsystem 0x00000003 > > > .file alignment 512 > > > .corflags 0x00000001 > > > > > > .class private auto ansi beforefieldinit Test > > > extends [mscorlib]System.Object > > > { > > > .method public hidebysig static void Main() cil managed > > > { > > > .entrypoint > > > .maxstack 1 > > > ldc.i4.1 > > > newarr [mscorlib]System.SByte > > > call void Test::Func(unsigned int8[]) > > > ret > > > } > > > > > > .method public hidebysig static void Func(unsigned > int8[] b) cil > > > managed > > > { > > > .maxstack 0 > > > ret > > > } > > > > > > .method public hidebysig specialname rtspecialname > > > instance void .ctor() cil managed > > > { > > > .maxstack 1 > > > ldarg.0 > > > call instance void [mscorlib]System.Object::.ctor() > > > ret > > > } > > > } > > > > > > Regards, > > > Jeroen > > > > > >
