Representation and Identity

re: Representation and Identity

Goran — Thu, 19 Mar 2009 20:28:41 GMT

Just what I was wondering about last week. As always - clear, precise and informative post. Thank you!

re: Representation and Identity

holatom — Thu, 19 Mar 2009 20:42:43 GMT

Very nice article. I have been waiting for someone to "deal" with this issue a very long time.

Additionaly the only difficulties with this is in generics classes - best way to address this problem is technique like this:

public static class DynamicConverter<TFrom, TTo>

{

private static Func<TFrom, TTo> converter = CreateExpression<TFrom, TTo>(body => Expression.Convert(body, typeof(TTo)));

public static TTo Convert(TFrom valueToConvert)

{

return converter(valueToConvert);

}

public static Func<TFrom, TTo> Converter

{

get { return converter; }

}

private static Func<TArg1, TResult> CreateExpression<TArg1, TResult>(

Func<Expression, UnaryExpression> body)

{

ParameterExpression inp = Expression.Parameter(typeof(TArg1), "inp");

try

{

return Expression.Lambda<Func<TArg1, TResult>>(body(inp), inp).Compile();

}

catch (Exception ex)

{

string msg = ex.Message; // avoid capture of ex itself

return delegate { throw new InvalidOperationException(msg); };

}

public static class DynamicConverter

{

public static TTo Convert<TFrom, TTo>(TFrom valueToConvert)

{

return DynamicConverter<TFrom, TTo>.Convert(valueToConvert);

}

than you can do something like:

var converted = DynamicConverter.Convert<sometype, T>(source);

in you generic class if you know than this conversation from sometype to T exists.

re: Representation and Identity

Matt — Thu, 19 Mar 2009 21:56:26 GMT

You've run out of foot note characters here's a few more ‖, ¶. :)

Lovely reasoning, I've often been annoyed at the unboxing convention so it's nice to see a rationale why it doesn't do it.

re: Representation and Identity

configurator — Thu, 19 Mar 2009 22:36:21 GMT

Great. Now can you please explain to the people I used to work with that unboxing an int by using Convert.ToInt32(obj) is bad for their health?

re: Representation and Identity

John Rayner — Thu, 19 Mar 2009 23:35:16 GMT

Great post, Eric, as always. Very informative and thought-provoking. And I think this one must get the record for the most footnotes ever used in a blog post! :-)

re: Representation and Identity

Kevin Westhead — Fri, 20 Mar 2009 00:33:42 GMT

Interesting post. Do you know what the reasoning was behind the unbox instruction throwing InvalidCastException rather than having another exception type specifically for unboxing failures?

re: Representation and Identity

Pavel Minaev [MSFT] — Fri, 20 Mar 2009 01:40:39 GMT

> Do you know what the reasoning was behind the unbox instruction throwing InvalidCastException rather than having another exception type specifically for unboxing failures?

Why not? Semantically, unboxing is a downcast ("this is B which I know is a D - give me that D" - "this is Object which I know is an Int32 - give me that Int32"). It's not identity-preserving simply because value types do not have inherent identity, but otherwise I consider it the same thing, so it makes sense to me that the same exception is used to indicate failure in both cases.

Of course, it is also possible to set the issue of identity preservation aside entirely, and just say that _all_ conversions deal with representations, and Base->Derived cast is also a conversion that translates a value of type "reference to Base" to _another_ value of type "reference to Derived" (the fact that the bit pattern may remain the same as a result is irrelevant). If you look at it that way, identity does not even enter into the question, because the value converted - which is the reference, not the object - does not have any identity. Also, from this POV, it makes more sense to have a single cast/convert operator.

re: Representation and Identity

Rob — Fri, 20 Mar 2009 02:00:48 GMT

I had a need for calling the conversion operators on a boxed value back in .net 2 so I wrote a basic dynamic cast method similar to what holatom is suggesting. It's here:

http://codegoeshere.blogspot.com/2007/05/dynamic-cast-in-c.html

This was a very targeted scenario, though, and I don't think I've needed it since.

re: Representation and Identity

commongenius — Fri, 20 Mar 2009 03:24:26 GMT

VB's CType operator caters to those who would rather not think about the different kinds of casting by generating the smallest amount of conversion code possible given the type information known at compile time. For example, CType(1, Integer) will actually not generate a cast at all, since the compiler knows it is unnecessary. CType(myInt, Long) will generate a conversion operation, the same as (long)myInt; while CType(myStream, MemoryStream) will generate a preserving conversion ("castclass" IL instruction), the same as (MemoryStream)myStream. Additionally, CType(myBoxedInt, Long) will generate a call to a VB helper function which will eventually cast the boxed int to IConvertible, and use that interface to convert to an Int64; this essentially performs the same function as (long)(int)myBoxedInt, although there is a performance cost. But, CType will still give you a compile time error if you try a conversion which is not possible under any circumstances (say, CType(myBoxedInt,

I am not generally in favor of CType; I prefer explicitly stating the kind of conversion that I know is necessary (which is probably why, or indicative of why, I prefer C# over VB). But the existence of CType is interesting to me because it dramatically demonstrates the difference in philosophies between the languages. C# forces you to prove that you know what you are doing (and in the process often forces you to think through what you are doing, and maybe do it better). VB allows you to say, "I don't care how you do it, don't bother me with the details, just get it done." Of course, if it CAN'T be done, you still get an exception, which you may have been able to find at compile time if you were forced to think about it.

Indeed, this does highlight an important difference in design philosophies. I like to say that VB is a "do what I mean" language, C# is a "do what I say" language. -- Eric

re: Representation and Identity

Pavel Minaev [MSFT] — Fri, 20 Mar 2009 03:47:36 GMT

> VB allows you to say, "I don't care how you do it, don't bother me with the details, just get it done."

From what Eric says, it seems that (T)(dynamic)x would do just that in C# 4.0.

Fabulous Adventures In Coding : Representation and Identity

DotNetShoutout — Fri, 20 Mar 2009 06:55:33 GMT

Thank you for submitting this cool story - Trackback from DotNetShoutout

re: Representation and Identity

Senthil Kumar — Fri, 20 Mar 2009 09:42:19 GMT

As I understand it, the issue is that the actual type of the object is unknown until runtime, so the compiler can't possibly know how to convert an unknown type to the type specified in the program.

Would a virtual method defined on object, say T Cast<T>(), solve the problem? That way, the compiler can issue an unbox, emit the virtual call to the unknown type and let it deal with problem if it wants to?

Sure, if we had generics in .NET v1 that would have worked. Basically you would be putting the onus on the developer of the type to provide conversions to arbitrary types. I like that in theory; I like thinking of a type as "a set of values associated with a set of conversion rules". Such a system encapsulates that concept nicely. But that ship has sailed; we did not have generics in v1 and we're not going to add new virtual methods to object now. -- Eric

re: Representation and Identity

commongenius — Fri, 20 Mar 2009 20:58:19 GMT

pminaev said:

"> VB allows you to say, "I don't care how you do it, don't bother me with the details, just get it done."

From what Eric says, it seems that (T)(dynamic)x would do just that in C# 4.0."

Not exactly. VB uses CType as a universal conversion operator, which will generate the most efficient form of conversion possible wherever it is used. You don't have to think about which type of conversion you are doing in different circumstances, because you are using the same operator. In the worst case, where no type information is known (i.e. casting from Object), the least efficient form of conversion is used (which basically tries each kind of conversion in turn). Casting to dynamic in C# 4.0 essentially removes all type information, forcing you into the least efficient conversion, even if a more efficient conversion could have been performed had the type information been preserved (such as in the (int)(long)myBoxedLong case). The dynamic version is slightly better though, since it caches the results of the conversion overload resolution.

re: Representation and Identity

Pavel Minaev [MSFT] — Sat, 21 Mar 2009 00:20:50 GMT

> Casting to dynamic in C# 4.0 essentially removes all type information, forcing you into the least efficient conversion, even if a more efficient conversion could have been performed had the type information been preserved

I don't see any reason why the compiler wouldn't be able to optimize the case of casting a value of type definitely known at compile-time to dynamic, as in my example - at least in theory. I doubt that the actual implementation in .NET 4 will do that - it seems to require too much effort for very dubious value - but it is certainly possible to optimize it in precisely the same way as CType does (since, after all, it has all the same inputs!).

Indeed. Our philosophy for "dynamic" is "you said dynamic, so you meant dynamic, so you'll get dynamic." We have certainly considered doing compiler work to detect situations where we know at compile time that a dynamic call cannot possibly succeed, or detect situations where the compiler can deduce enough type information about the dynamic thing to skip making a dynamic call. As you correctly call out, this is an immense amount of work for bizarre corner cases that directly contradict the stated intention of the programmer -- if the programmer says they want dynamic dispatch that might fail at runtime, that's what they'll get. -- Eric

re: Representation and Identity

Pavel Minaev [MSFT] — Sat, 21 Mar 2009 09:33:42 GMT

> As you correctly call out, this is an immense amount of work for bizarre corner cases that directly contradict the stated intention of the programmer -- if the programmer says they want dynamic dispatch that might fail at runtime, that's what they'll get.

Will that be a hard requirement in the language spec, however? I.e. will the conforming compiler be required to defer the error until execution even if it can see that it is going to fail at compile time already? Or is it implementation-defined?

I think it doesn't touch the original case we discussed either way, though, as it wasn't about an error case - it was merely about optimization for the successful case. Something like (int)(dynamic)1.0 cannot fail, and if the compiler is smart enough to handle that at compile-time, the "as if" rule should kick in.

re: Representation and Identity

Anthony D. Green — Thu, 02 Apr 2009 00:34:07 GMT

"VB allows you to say, 'I don't care how you do it, don't bother me with the details, just get it done.'" (commongenius).

Indeed we call that declarative programming. This is a quality of markup languages, SQL, RegularExpressions and highly desirable in many cases.

This is not to say that it's always desirable indeed I appreciate the recognition of a valid though different philosophy. I've recently come to terms with CType - until recently I was more fond of DirectCast because of its explicitness. I also sort of liked that the VB implementation of CType vs DirectCast separated out the two functions of the C# cast syntax - i.e. Conversion (representation-changing) versus Casting (identity-preserving). I've since decided that I was just being needlessly obsessive and that differing to the tool to exercise the most appropriate (hopefully optimized path) method was maintenence-wise more concise (or consistent).

Ultimately it's a choice between who gets the burden for optimizing implementation - the SQL Server team has to be deligent when emitting query plans to use all information to produce the query plan that's most efficient whereas with the more explicit - imperative style the burden is shifted to the user. I prefer the former but always appreciate the option to go explicit as required but I think it's most important for the programmer to be aware that in these cases they are delegating responsibility to the tool - that it's not just magic.

"VB is a 'do what I mean' language, C# is a 'do what I say' language " (Eric).

I like this summarization. I rings well with my discoveries about some of the finer rules of Option Strict Off in VB (which is an advanced language feature, btw, not a novice one - which is why it should be off by default). A lot of people characterize it as a feature that let's you just willy nilly do anything and everything and the compiler will just make things happen by parsing horoscopes. This is not true. When you look at the rules it won't let you do anything that you couldn't say explicitly (and can still give compile time warnings for things it knows you definitely can't do) and even being explicit about the cast/conversion it's still just as possible to ask to do something that will fail (I would argue that having to type CType doesn't actually make me more likely to realize a conversion will fail at runtime but then again I don't do a lot of conversions anyway)

It's a philosophical difference of whether I have to say Dim i As Integer = CType(o, Integer) or whether it's sensible for the tool to infer from my assining o to i that I would naturally want - need - mean - to convert o to an Integer first - whether I should have to say something that I'd have to say anyway.

Good read.

Fabulous Adventures In Coding : Representation and Identity

DotNetKicks.com — Fri, 17 Apr 2009 15:41:57 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com

re: Representation and Identity

Wardy — Mon, 11 May 2009 14:20:29 GMT

I think that all went straight over my head ... dam I feel stupid now, time to get those mcts books out.

re: Representation and Identity

Tom — Thu, 06 Aug 2009 16:41:51 GMT

I'm a new fan of your series. Keep these fantastic articles coming!

One correction: Nullable<ValueType> is not imiplicitly convertable to ValueType. It's the other way around.

re: Representation and Identity

Tom — Thu, 06 Aug 2009 16:46:39 GMT

Sorry for the repost, wanted to provide a sample. If you can merge these two posts, please do.

int i = 0;

int? j = null;

int i = j; // won't compile

int i = (int)j; // throws InvalidOperationException

int i = j ?? 0; // works

re: Representation and Identity

Eric Ouellet — Fri, 11 Dec 2009 19:01:05 GMT

Hello Eric,

I red your nice article.

I don't know if it is because I missed somthing important but I feel that C# could support something like that:

// ******************************************************************
       public class Something       {       }
       // ******************************************************************
       public class SomethingWrapper
       {
           private Something _something;
           public static implicit operator Something(SomethingWrapper wrapper)
           {
               return wrapper.GetSomething();
           }
           public Something GetSomething()
           {
               return _something;
           }
           public SomethingWrapper(Something something)
           {
               _something = something;
           }
           // More code here...
       }
       // ******************************************************************
       private void button1_Click(object sender, RoutedEventArgs e)
       {
           SomethingWrapper sw = new SomethingWrapper(new Something());
           Object o = sw;
           Something s = (Something)o; // InvalidCastException.

If it exists only one way where the compiler could pass from "Object"(real object: SomethingWrapper) to "Something" object,

then why the compiler does not create the code and just do it ?

Why it would need dynamic type for that ?

Why not doing it on object ?

In order to make your scenario work, the generated code has to start the C# compiler, run overload resolution to determine that there is a conversion from the runtime type of the object, somehow call the conversion, and return the result. Remember, we have to run this code on EVERY cast. That would make C# a very slow language indeed. Now, if you want to start up the compiler again at runtime, in C# 4 you can do that if you choose to take that performance hit. Make the argument dynamic, and we'll do all the analysis at runtime. -- Eric

If it would be supported, it would open the door to a fantastic world of generic wrapper classes.

SomethingWrapper could be generics to works on anything, not only Something.

Am I wrong ? Did I missed something somewhere ?

Thanks

re: Representation and Identity

Eric Ouellet — Fri, 11 Dec 2009 21:59:28 GMT

Thanks Eric for your feedback, it was very quick !

I absolutely do not want to use "dynamic" typed object. It's untyped (no intellisense and many more, you know all that...). By definition is bad to use it!

Althought the compiler is able to do portion of the discovery on the fly, actually (it could change), I do not want to touche dynamic object with a 10' pole.

Related to my previous sample...

I would probably be able to do:

something s = (dynamic)o; // Pass throught dynamic object to do dynamic cast to typed type ?

Does the language will offer a new keyword of the style "dynamic_cast"... Will I be able to write:

c#3.5 : Something s = (Something)o; // InvalidCastException.

c#4 : Something s = dynamic_cast<Something>o; // Find the path to the object, throw an exception if more than one path available (no dynamic objec)

That dynamic_cast is very nice... Hope Anders thought about it for C#4 !!!

re: Representation and Identity

Eric Ouellet — Thu, 17 Dec 2009 20:32:30 GMT

In fact, I do not understand why cast could not cast its source to its real underlying object type source before trying to cast ?

Why I can't do that, and why it would cost a lot to do it ?

public class EnumValueWrapper<T>

{

// **************************************************************

private readonly T _enumValue;

// **************************************************************

public EnumValueWrapper(T enumValue)

{

_enumValue = enumValue;

}

// **************************************************************

public static implicit operator T(EnumValueWrapper<T> enumValue)

{

return enumValue.GetEnumValue();

}

// **************************************************************

public T GetEnumValue()

{

return _enumValue;

}

... // Elided for clarity

}

...

public enum FirstLast { first, last };

FirstLast firstLast;

EnumValueWrapper<FirstLast> firstLatsWrapper = new EnumValueWrapper<FirstLast>(firstLast);

Object objFirstLast = firstLatsWrapper;

firstLast = (FirstLast)objFirstLast; // Exception

The compiler already as to do a check at runtime to ensure inheritance compatibility. There is already a kind of performance penalty.

It could pregenerate code like (pre IL):

firstLast = (FirstLast)objFirstLast; ==> firstLast = (FirstLast)(objFirstLast.GetType())objFirstLast;

Everything would work perfectly and the cost would be minimal (I think). Are you agree ?