Turbo C# is available now.

I blogged about this 2 weeks ago. The install had been smooth (besides that I had to install .NET 1.1?!) and at look quite clean. The IDE cannot deny that is is made with .NET:

Well, Borland a little bit more work, even for a free product would have suited you better, the installer and the registration are so 90ty.

Perhaps it gets better in 100 years, when I have to register a new copy:-)

After some assembler (8080!), the first programming language I learned had been Turbo-Pascal. If I remember correctly; it could not have been Turbo, as I was 12 years old at that time and Turbo did not yet exist then - well it does matter that much - I definitely used Turbo-Pascal later.
Borland seemed to find the name “Turbo” not very professional, so they dropped it. As IDEs are now a commodity, the professional touch is gone and the Turbo is (nearly) back!

As C# has some appeal to me, it looks like I could use another creation of Anders Hjelsberg…

Remember http://www.javalobby.org/java/forums/t74270.html?start=0? It seems that everybody read and replied on it:-)

Nearly all proposals made (even the one I added my self) have a serious problem: They don’t play well with interfaces.

First I like to define what I mean when I talk about a Property:

A Property is a member where get().equals(get()) and set(x) => get().equals(x).

The java.util.Properties fulfill this condition nicely, as do simple members like names, etc. The Properties-class was actually what got me the idea: As I was faced at work of writing hundreds of getter/setter and member declarations, I took a short-cut and handled this by named attributes. The only thing we lost (besides some CPU-cycles) was type-safety (not a concern in the situation) and the clear binding that allowed refactoring (important then, no issue now). Most of non-trivial get/set are actually interceptors that don’t modify the behaviour from a simple member access. If this is not true you don’t a have Property in the sense of this text.

Why the concept of properties at all? Because it carries important semantics. The user of a property is encouraged to rely on this, this will simplfy code and makes programm more stable if the rule can be checked by an “meta-assert”.

So general advice, if “dynamic” properties will do: Go for it, especially in web-programming where you can spit out String for numbers and dates.

Well, I admit that this is not too satisfying, so here a better solution, but it’ll require a JSR:

The property keyword

The keyword property is somewhat similar in it use as the enum keyword.

property {
int a,
String b,
HashMap m
}
Read the rest of this entry »