You are correct about the generics. I think C# is getting support for contravariance and covariance in 4.0, which should all something that takes base type of a generic to take a subtype.

The Java enums are a bit heavy, but it is pretty useful when you need it. I agree with you that there might be a better solution, but between the two I have to go with the Java implementation.

Also I disagree about Enums, as much as I’m not a huge fan of C# Enums (too lightweight) I think Java ones are just as annoying but in a completely different way (too heavy).

56.toString

Scala 2.8 has manifest types which allow you to reflect on the type parameter T so some of the examples you show there are possible.

Scala doesn’t have checked exceptions.

Scala’s for comprehensions allow you to write the kind of code that LINQ’s magic is for.

val query = names.filter(_.length == 5).sorted.map(_.toUpperCase)

Scala has type inference so you don’t need to specify types in many places.

Scala has implicits that let you add methods to any class and pick the scope where those additional methods are visible. For example, Scala has a RichString class that has additional methods beyond String. It’s not like Ruby where if you extend a class the entire process sees those modifications, in Scala, the additional methods are only visible where you want them and it’s done at compile time.

Regards,
Blair

12.4.2.5 Overview of exception handling
See the exception handling specification in Partition II for details.
Each method in an executable has associated with it a (possibly empty) array of exception handling
information. Each entry in the array describes a protected block, its filter, and its handler (which shall be a
catch handler, a filter handler, a finally handler, or a fault handler). When an exception occurs, the CLI
searches the array for the first protected block that
• Protects a region including the current instruction pointer and
• Is a catch handler block and
• Whose filter wishes to handle the exception
If a match is not found in the current method, the calling method is searched, and so on. If no match is found
the CLI will dump a stack trace and abort the program.
[Note: A debugger can intervene and treat this situation like a breakpoint, before performing any stack
unwinding, so that the stack is still available for inspection through the debugger. end note]
If a match is found, the CLI walks the stack back to the point just located, but this time calling the finally and
fault handlers. It then starts the corresponding exception handler. Stack frames are discarded either as this
second walk occurs or after the handler completes, depending on information in the exception handler array
entry associated with the handling block.

Yet, I have created a small program that does:

try
            {
                Console.Out.WriteLine("In Try");
                throw new Exception();
            }
            finally
            {
                Console.Out.WriteLine("In Finally");
            }

Which outputs:

In Try

Unhandled Exception: System.Exception: …

In Finally

So it obviously does call the finally block. I will update the post to reflect that. Thanks for bringing that point up.

int? i = 0;
Nullable j = 0;

(i.GetType() == j.GetType()) == true;

I agree with some of the other commenters that the nullable value types are most often used in database scenarios, but sometimes the abstraction is useful to represent the lack of information even in non database contexts.

I always wondered why have my organisation has done this extra work for. But to be honest, for every java based open source ApI out there, I realised it is not worth to go for one until its third release or over.

Finally switched to C# and programming happily ever after. One language, One ID and focused.