Architecture
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.
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)
