Subclass this

In object-oriented languages there’s a nifty feature called code inheritance. People tend to think that this is a really cool ™ thing, since it allows you to quickly slab some new features onto a class whenever the need arises. In fact, there still seems to be a lot of folks who think that the whole point of object-orientation is to subclass a lot.

I’ve previously worked with Microsoft MFC, which was designed that way (but remember, that was back 1992) – as was the class hierarchy that makes your Unreal Tournament tick. I’ve seen object hierarchies spreading over 15 levels, and more.

The only problem with code written that way is that it sucks. A lot.

Continue reading “Subclass this”


Strange variable scopes – Class variables (part 1)

There we go again. Ruby has some, err… “unique” features when to the scope of variables. It really starts out really harmless, though…

This is part one of two – this one is just to give you a bit of background for the next one. There’s not much surprising stuff there, so if you want to go for the stranger bits, just jump to the next installment.

Adding methods at runtime

One of the things that seems to draw people to Ruby is the ability to create and change all things at metprogrammatically at runtime. This in turn allows users to create things like domain-specific languages and the like.

I’m possibly overusing these features at the moment, because it’s a cool new thing ™.

So, let’s see how to add methods at runtime. Since this is Ruby, there are multiple ways to do this, making things more confusing.

(See also the follow-up article)

Ruby overloading

A new thing on my quest to learn the new language is weird inconsistency that bugged me lately: In Ruby you can overload virtually everything. That is, everything except the “equals” operator.

In spite of this, half of the Rubyists seem to believe that they overload the “equals” sign all the time.

Still, if you have this kind of expression:

variable_1 = variable_2

it will assign the value of variable_2 to variable_1, and there’s no way to change this behaviour.

However, if have something that looks like this

object.method = expression

the code will actually be evaluated equivalent to

object.send(“method=”, expression)

Continue reading “Ruby overloading”

Ruby notation

Ok, we all knew that Ruby is very dynamic. The fun part starts if you start thinking about your own notation. It turns out, it’s even more loose and fast than I thought. So consider this:

obj =

obj.do_something(params) # this calls the method with parameters
obj::do_something(params) # this is actually the same thing (calls do_something)

obj.do_something:cool # and this call the method with the parameter :cool
obj::do_something:cool # ok, and now it’s getting funny

obj.Will_do # uppercase method names also work on objects

# so, for classes

Klass.do_something # this will call the class method, of course
Klass::do_something # and this also calls the method
Klass.UpperCase # and this calls a class method with an upper case name
Klass::UpperCase # BUT THIS CALLS THE CONSTANT (go, figure…)

The nice thing is that you can really start thinking of your own notation for things. Still, it’s great weirdness notheless…

Rails and AJAX

I my ongoing quest to learn more Rails, I tried to do some (more or less) fancy AJAX stuff. And even though Rails afficinados claim “seamless” support, AJAX is a pile of hacks. Rails at least makes it a bit less painful.

In any case, there are some resources that can help you to get along:

Basically, the in-place-editing gets a bit more involved once you want to edit more than one object on the page…

Dispose my $%!

I’ve just come across you particularly annyoing feature in the new Version of the C++ Managed Extensions for .NET.

For garbage-collected languages, it is recommended that you follow the “Dispose” pattern in order to free non-memory resources. That’s a well established pattern, if you want to know more about it you can read here or here. There are a few rules on how to implement this pattern. Microsoft also added an interface for disposable objects, that allows for some syntactic sugar.

However in the “new” version of the Managed Extensions for C++, they came up with a different way to implement the dispose pattern. This mimics the way destructors work in plain C++.

They also came up with the brilliant idea that it should not be allowed to call the Dispose() method directly:

From a Microsoft blog:

A bit of discussion about Dispose brought up an interesting point – in C++, now, we’ve disabled the ability to call the Dispose function directly. Instead, you call it thusly:

ref class MyClass{
~MyClass(){} //overrides IDisposable::Dispose()

int main(){
MyClass^ mc = gcnew MyClass();
//do stuff
mc->Dispose(); //error!
mc->~MyClass(); //legal, calls Dispose()
delete mc; //also legal, also calls Dispose()

Now, whoever came up with that should be kicked in the butt. Quite hard.

Create a free website or blog at

Up ↑

%d bloggers like this: