Wednesday, March 26, 2008
.Net Type Safety
Working with the ternary(conditional) operator in C# I came across an interesting problem. The following piece of code does not compile.
The above code fails with an error that " there is no implicit conversion between
On the contrary with enums where type checking is expected there is no type checking!
The above call
class Cat{}
class Computer{}
......
Object obj = need_a_cat? new Cat():new Computer();
......
The above code fails with an error that " there is no implicit conversion between
Cat and Computer". That is correct ;).However still wondering why is a type checking required in the above case.On the contrary with enums where type checking is expected there is no type checking!
enum Day_Of_Week { sun, mon, tue ....}
String DoSomething(Day_Of_Week day) {
.......
}
....
DoSomething(Day_Of_Week.sun+109);
The above call
DoSomething(Day_Of_Week.sun+109); should have failed during compilation. But it doesn't ;)
¶ 11:38 PM
Comments:
<< Home
The first part can be stated like this: every expression must be well-typed. Why isn't there an exception for the ternary operator? The simple answer is: special cases are a bugger and who wants to deal with them. If you consider implementing it, though, you then have to consider that you can end up with an exponential tree by nesting ternary operators.
This is far from insurmountable, as Haskell demonstrates... most languages have a very simple type system.
In the case of enums, you have to remember that an enum type is dressing for an underlying integer type (int by default). So, the addition operator causes an implicit cast to int and then passes that in. This behavior is a throwback to C...
This is far from insurmountable, as Haskell demonstrates... most languages have a very simple type system.
In the case of enums, you have to remember that an enum type is dressing for an underlying integer type (int by default). So, the addition operator causes an implicit cast to int and then passes that in. This behavior is a throwback to C...
With the current .Net implementation of the ternary operator, I cannot do what is supported by the if-else without an explicit cast
Object SomeMethod(){
if(need_a_cat)
return new Cat();
else
return new Computer();
}
.
Java has a slightly different implementation which would let you do the same thing as the if-else using the ternary operator, without any surprises.
Object SomeMethod(){
if(need_a_cat)
return new Cat();
else
return new Computer();
}
.
Java has a slightly different implementation which would let you do the same thing as the if-else using the ternary operator, without any surprises.
As Nikolas said C# ternary operator does enforce well-typed expression. I agree it's sometimes annoying but just think about more complicated scenarios like "nested ternary operators"?
And in enumerations, I don't see how Aslam's code fragment compiles in C#? Throughout all my 8-9 .NET years I've been using explicit-cast operator treating enums as integers!!! Aslam are you sure it does compile with default vendor-supplied compiler settings? :-? Will be pleased if you keep us tuned! :)
Also check my post here (not out of context): http://blog.mavadat.net/2008/05/c-covariance-and-contravariance.html
And in enumerations, I don't see how Aslam's code fragment compiles in C#? Throughout all my 8-9 .NET years I've been using explicit-cast operator treating enums as integers!!! Aslam are you sure it does compile with default vendor-supplied compiler settings? :-? Will be pleased if you keep us tuned! :)
Also check my post here (not out of context): http://blog.mavadat.net/2008/05/c-covariance-and-contravariance.html
Ooppppppppssss!!! Aslam's code fragment is like "MyEnum e2 = MyEnum.First + 109" not "int i2= MyEnum.First + 109"
Mee too likes guarding enumerations as normal OO types! Language implementors are free using integral stuff as underlying storage, but shouldn't mess up its integrity!!! This is why exactly C# programmers should always be expecting something out of defined enumeration value list - e.g. no switch-case without a default!
Post a Comment
Mee too likes guarding enumerations as normal OO types! Language implementors are free using integral stuff as underlying storage, but shouldn't mess up its integrity!!! This is why exactly C# programmers should always be expecting something out of defined enumeration value list - e.g. no switch-case without a default!
Subscribe to Post Comments [Atom]
<< Home
