Comparing C# and Java
Subject:   c# for java programmers
Date:   2002-12-30 06:39:04
From:   anonymous2
I have read a lot of articles on how c# is or is not like java but I think until you start to code C# you don't really notice the differences between the two languages.

C# is a newer language and thus necessarily has new features. The question is will they help or not. Here is my list of things that give me problems:

1. namespaces, packages and assemblies. Everyone says the that a package and a namespace is the same and so is an assembly. But they are not the same thing. Packages in Java determine the fully qualified names of classes and also determine class/method/field accessiblity for package accessibility. No matter how you deliver your classes (i.e. what classes you make available in your jar) your package accessibility does not change. With C#, namespace is just a text prefix to the name of a class and has nothing to do with accessiblity. So you can't use a namespace to hide a method from a set of classes. Further, the "internal" accessibility modifier changes with respect to how you create your dll's. So this is not like package visibility either.

The result is in java you might have lots of packages and you often put everything in 1 big jar, while in .NET you are going to have lots of dll's with few namespaces each. Otherwise you will be exposing too much functionality in the "internal" "namespace".

2. I have trouble with delegates being an "object oriented" function wrapper. The idea being a function wrapper and object oriented seem to be incompatible. I may just be getting old, but I don't think delegates are an advancement in the right direction. I think the idea of interfaces to implement the publish/subscribe (observer) pattern is not bad and I must say I prefer the publish/subscribe pattern of java to the callback techniques of, say, Xlib. It seems delegate are just a return to the old callback functions.

3. I miss anonymous inner classes. Why didn't they put this in c#. They provide a very elegant technique for solving a lot of common implementation problems. I suppose that delegates are suppose to take up the slack here, but (as I said before), I don't much care for delegates.

So in total, while C# does provide some new features - some good (like foreach, and using) it also has some less good features (for example, I think attributes make the job of tool vendors easier, but just polutes good application code with cryptic compiler directives). What we need are articles that are neither anti-c# nor (and there are a lot of these) pure microsoft marketing talk. We also need a good set of standard c# idioms and best practices (without the marketing).