Slag and inheriting constructors

[Paul]

With Slag 2.0 coming out soon, I thought this might be a good time to
return to an old favorite problem.

The problem is that the Slag compiler allows you to call the
contructor of a superclass, even if that constructor does not exist in
the subclass. Here's an example. Say you create a class GUI. You
can instantiate the class and use it no problem.

class GUI
PROPERTIES
widgetList : Widget[]

METHODS
method init():
widgetList = Widget[](10)

endClass


Suppose that now you're using your GUI class in a few places. You
then decide to extend the GUI class and create a SpecialGUI class
(which happens to have the same constructor) that adds some neat
effects to your guis. And so you're using a few instances of GUI, a
few instances of its subclass SpecialGUI, and everything is fine.

Now you decide that you want to add some functionality to SpecialGUI,
because you want it to perform some effects based on the state of the
game. So you go ahead and add a parameter to the constructor of
SpecialGUI, called someGameData, intending ALL SpecialGUIs to have
this parameter filled in.

class SpecialGUI : GUI
PROPERTIES
someGameData : GameData

METHODS
method init(someGameData):
endClass


You make the change to the constructor, and try to go find each line
where you instantiate a SpecialGUI to fill in this new parameter. But
let's say you missed a couple of places: in two Slag files, residing
in different directories, you instantiated some SpecialGUIs and forgot
to change the constructor.

In Slag, there is no compiler error because it assumes you want to
call the empty constructor of its superclass(GUI). In Java, it sees
that SpecialGUI has no empty constructor, and doesn't compile.

In Slag this has caused problems for me for a long time. And the bugs
can be very tough to track down--maybe SpecialGUI doesn't crash
without its someGameData reference unless very specific conditions are
met, so just instantiating the SpecialGUI at run time isn't even good
enough to find the bugs. Unfortunately, you can't just make GUI
abstract (which would block this constructor call), because you do
have legitimate instances of GUIs.

Correct me if I'm wrong, but I believe in Slag 1.0 the "limited"
keyword keeps you from making this implicit call. Honestly I've never
wanted to implicitly call the constructor of a superclass, I would
much rather just lose this functionality than have to deal with all
the bugs that it creates, or have to remember to put a special keyword
before every class I write. If a programmer really does want to be
able to call the superclass's constructor, it seems like THAT would be
the special case, and it's not a big deal to put in a prior.init()
line to save all of the hassle I just mentioned.

I know that was a long rant, but I just ran into this bug again for
the umpteenth time, in a weird place, and it stirred up my
frustration.

Any thoughts?

[Abe]

So how about this:

If you don't define any initializer then all initializers are
inherited.

If you define even one initializer then all inherited initializers are
hidden.

Sound good?

[Paul]

That sounds perfect!

> > Any thoughts?- Hide quoted text -
>
> - Show quoted text -

[Abe]

Done!