Re: Check this out for a good laugh

> T! is the "option type" for T, right? because T?
> is the "nullable type" and it's already in C#. T?
> meaning it's value is either a T object or null. T!
> meaning it must be a T object. T meaning we don't
> care, so for [T resolves to List] it means T can
> either be a List or null, but naturally for [T
> resolves to int] the null case cannot possibly arise
> because it is a primitive thing. am I right?

As long as it isn't autoboxed into an object. And in places where you 
would need to set a null into a primitive type, like in collections, the 
value will be boxed in the object already.

> Nice is much more coherent in my opinion.

Nice is closer to Java/C++, which is fine with me.

> the sort of optimization you are talking about is of
> course welcome, but I was basically worried about
> this: if the language does not make *any* distinction
> between primitive types and reference types, should
> this affect performance? I guess the only reason Java
> decided that int's won't inherit Object was this
> performance issue.

http://scala.epfl.ch/intro/unifiedtypes.html
An objects might be a primitive object (AnyVal),
or a referenced object (AnyRef).

> or maybe I am wrong. if you call a method with either
> an integer variable or a struct (in C#, they are value
> types), the value is copied and anything you do to
> them (like changing the value of a field in the copied
> structure) does not affect the original. so structs
> are passed by value. M$ claims that as for this
> strategy (the copy of) the struct is placed in a stack
> rather than allocated in a heap, things are faster. so
> structs being lightweight pays off. are they right?

Stack allocation is MUCH faster then the heap one. In fact, stack 
allocation takes ZERO time, while fastest heap allocation is comparable 
to HashMap access. But modern JITs can stack-allocate common objects: 
they tear the objects down to primitive types and work with these types 
directly, allocating them on the stack. M$ in this regard is again 
closer to C++, where the explicit choice between stack and heap 
allocation is the part of the language design. Once again, this might be 
due to the idea of implementing the managed C++ on CLR.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php