skizz.biz

Me>C# is just java with (often poorly thought out) additions
Zohar >Interesting. Which additions do you consider poorly thought out?

Well here’s one: Properties.

C# says:

public Foo Foo
{
set {this.foo = value;}
get {return foo;}
}
...
someFoo = Foo;

where java would say

public Foo getFoo() {return foo;}
public void setFoo(Foo foo) {this.foo = foo;}
...
someFoo = getFoo();

So what?

Well here’s some reasons I dislike this:

1. It is impossible in C# to have a setter at a different protection level to the getter. If you want a protected setter, you need to define a protected Foo SetFoo(Foo foo). Kind of defeats the purpose.

2. It is impossible in C# to overload a setter. This means that you can’t have what in java world would be good practice:

public void setFoo(Foo foo) {this.foo = foo;}
public void setFoo(MyFooLikeThing fooLikeThing) {
setFoo(fooLikeThing.asFoo());
}

You can of course still do this sort of thing in C#, but it is not overloading — the developer needs to know that x.Foo = foo and x.SetFoo(fooLikeThing) are the same thing. Two different syntaxes for the same operation does not aid easy comprehension or code readability.

3. In java it is clear if you do a = x.foo that you are not doing a function call and no side effect can happen. In C# a = x.Foo may be a simple getter or may instantiate a remote webservice. I can never know. And so I will assume the worst and comprimise my design to allow for the possibility that the get might do something expensive.

4. For some reason (probably to do at least partly with the limitations I mentioned above) the .NET libraries seem ambivalent on properties. Quite often you see x.GetFoo() where you might expect to see a property. the immediate questions are “Why is this not a property? What secret machinations are happening that means that it is not a prroperty? Should I treat this method differently to a true property?”. Truth is its probably just happenstance and the way the team felt on the day - but that doesn’t help me make a decision on how to use the method.

5. public Foo Foo {get;} — Come on! What were they thinking! Java’s Foo foo; is bad enough! At least there the case gives you a clue!

Of course all of the above is aesthetic. But that is what language is about — aesthetics and ease of comprehension.

(This is a bit of a retrospective for Ben and my Greece trip)

We met at the moroni fountain in Iraklion — for me this was after a 10 hour ferry trip from Athens sleeping on the floor, and then hanging around from 5:30.

Hanging around in the morning, walking past the Venetian fort as the sun came up, sitting in a square aas the church bells ring out the ‘Kyrie Eleison’ really put me in the mood for Greece. After the panic and stress of gettting there it was a good way to wind down.

After we had breakfast and I had dumped my stuff we decided to hire a car and go to Knossos. We decided that it was easier than catching busses around, and gave us more freedom. we ended up with a beaten up Suzuki — a glorified tin can on wheels — that smoked alarmingly for the first couple of hours.

More alarming even than the car were the Greek roads. Fortunately I have driven in Thailand, so I was used to traffic treating lane markings (if they exist at all) as optional guidelines. If you stick to the hard shoulder normally OK. In some ways its easier in Greece — you don’t generally have to watch out for water buffallo.

But we did get to Knossos, and parked about 1km away and walked back to the site. It was packed despite the heat, and we spent about 4 hours wandering around the palace, exploring every part we could get to.

Its an atmospheric place, even with the thousands of us tourists swarming over it. It is so easy to imagine people once living there — walking the same corridors we now see collapsed. The far past seems remarkably close — true of much of Greece.

Mike Porter pointed out a problem with the example in my last post.

In the example of usage it should of course say:

container.register(Boy.class, Boy.class);
Boy boy = (Boy)container.getComponent(Boy.class);

otherwise pico won’t have a chance to give the boy its Kissable.

Note to self - remember that cool idea you had about only ever putting source code into blogs that compiled and ran and had been copy-pasted directly from an IDE? D’oh :-)

By the way, the Kissable example is from a presentation of Aslak’s about Inversion of Control. I won’t go into the details here - but if we can get him to do it more widely you should be very afraid…

We started a scary spike last night — putting a transparent ‘Type 3’ Event Driven architecture in Pico.

The idea is simple — suppose I have a Kissable interface:

public interface Kissable {
public void kiss();
}

I add some Kissable things to my Type3MsgPicoContainer:

container.registerMulticasted(Kissable.class, new Girl());
container.registerMulticasted(Kissable.class, new Grandmother());
container.registerMulticasted(Kissable.class, new Baby());
container.registerMulticasted(Kissable.class, new BlarneyStone());
container.registerMulticasted(Kissable.class, new Boy());

I also add something that understands how to kiss:

public class Boy{
public Boy(Kissable kissable) {...}
public void doSomeKissing()
{
kissable.kiss();
}
}
Boy boy = new Boy()
container.register(Boy.class, boy);

If I now do boy.doSomeKissing(), an event is generated and queued internally and (asynchronously) all Kissables in the system get kissed.

Joe Walnes suggested we call this ‘Type 3 Messaging’ since it hides the implementation in the same way that Pico itself does — and looks like ‘plain old message calls’.

In tha spike we did last night (you can see the source code here ) we use concrete objects and support round-robin multicasting as well.

Other strategies migt be available too — for example a pooled implementation for database components, or a transparent SEDA style architecture.

I was reading Jeremy’s blog entry on GettingOutOfYourTeamsWay and it reminded me of something that struck us on InkBlot.

We were a self-selected team. Rather than the normal pattern of choosing a set of developers and throwing them together onto a project, we started with an already successful but idle pair and then others begged to join the team, until we hit the sweet spot of 6 developers.

This meant that we didn’t have to convince people of the approach, rather we chose the approach. It was very agile, and very successful. We chose our process and (surprise) it worked.

There were some things we didn’t do because we didn’t need to. For example we had no daily standups, because there was no need — our conversation was ongoing, and there was nothing to gain from repeating ourselves.

There is also a subtle difference between accepting resposibility and taking responsibility. We didn’t allocate cards by writing names on them (accepting resposibility). Rather we stuck them all on the board and took a new one whenever we finished the current card (taking responsibility). The funny thing was even the boring and difficult cards did get done.

I guess because the team took collective responsibility (by sticking them on the board) we felt that the honour of the team was on the hook if a card was ignored. And because (being self-selected) we cared for the honour of the team, we did the hard cards.

I liked it. Its a good way to work.

I’ve started on a new project. Its in .NET. The most interesting thing so far about .NET is how immature it feels.

And of course the fact that DevStudio is like getting on a bicycle after IntelliJ’s Ferrari. C#Refactory helps a bit, but I didn’t expect the development process to be as painful as it is.

I heard on of the SmallScript gurus talk at XtC about smalltalk on .NET a couple of months ago, and one of the things that stuck in my mind was his comment that smalltalk “didn’t feel the same” without the dynamic environment and the smalltalk refactoring browser. Its not the language that made it great, but the environment.

The same is true of java v .NET. After all, C# is just Java with (IMHO) some (often poorly thought out) additions. Even the class libraries are much the same as Java. There are some nice things, but not as many as I had expected.