Constructors aren't allocators!

I touched on this briefly in a previous post about best practices in REALbasic, but I think the topic deserves its own post entirely. In REALbasic, constructors are initializer methods, not allocator methods. When you say "new SomeClass", the compiler allocates *all* of the space for SomeClass, and then calls the first constructor it finds in the class hierarchy like it would any other method. So constructors are slightly magical in that the compiler automatically calls a method when you use the "new" keyword. But they're not really that magical at all. They're basically just a regular virtual method like anything else in your application. And just like any other virtual method, if you want the parent class to perform work as well as the child class, the child class needs to pass the call back up to the parent class. This means the child needs to call Super.Constructor.

Failing to call Super.Constructor isn't an error, because constructors aren't special. However, failing to call it could lead to some strange side effects, like the parent class not being entirely initialized as it may expect. So you should always call Super.Constructor (and this is behaviorally different from other virtual methods, where you don't always want to call the Super's implementation). That begs the question: why? Since constructors should almost always call up the chain, why do we have to do it manually?

The answer is two-fold: 1) Because that's the way it is. 2) Because it's more powerful. The first answer seems a bit lame, but it's still valid. That's the way it works, and we're stuck with it. Trying to modify the behavior now would break almost every REALbasic project in existence. What's more, the second answer really negates the desire to modify the behavior anyways. By making constructors into simple initializer methods, it solves a ton of problems. For instance, unlike other languages that shall remain nameless, you can use "self" in a constructor and it actually means something useful. Self is fully constructed, and so you never have to wonder what's going to happen when you call a virtual method. What's more, we allow you to control *when* initialization happens for the superclass, which allows the subclass to modify the behavior of the superclass. This allows a window subclass to determine when the Open event fires, for instance.

So, like anything in life, there are tradeoffs. You have to remember to call Super.Constructor on your own because the compiler won't do it for you automatically. The flip side is that there's a more consistent behavior when calling virtual methods (and in REALbasic, all methods are virtual), and you can control when initialization happens.