Since the dark ages of yesteryear Squeak has had a very interesting button in its Debugger – “create”. Today we’re going to teach it a new trick.
Suppose you write a test, showing how
bar. Your very first test case is simply
You try save the method. Of course,
Foo doesn’t exist yet, so Squeak prompts you to define the new class:
OK, you can now save the method. You run the test. Of course, it fails. So you click on the failing method, and see that you haven’t yet taught a
Foo how to
Ah, there’s a “Create” button. What’s it do? Ah, I see. It asks us which object in
Foo‘s hierarchy ought to understand this message. Let’s keep it at
Foo for now. OK, and now we see a stub implementation where we can enter our real code.
So far so good. Now suppose we need
Foo to supply a template method for its subclasses to impleement. In C# we’d mark the method as
abstract. In Smalltalk we mark the method:
Now we need to implement this behaviour in a subclass,
Bar. We write a trivial test, run the test, see it fail. If we click on the failing test we see a decent error message…
… but we have to leave the debugger to fix this. Can’t have that! Alright, let’s see what we can do. First we need to distinguish this kind of error from other kinds of errors:
Then we must actually throw the error:
Next we need to teach the
Debugger how to respond to this special error:
Here we see the other side of the comment in
Object >> #error:. A
ContextPart stores the variables relevant to that frame, and in a parameterless method, the first temp will be the first local variable, containing our exception. And we can simply reuse the (mildly extended) existing mechanisms for creating a stub method.
Hey, presto! Another reason not to leave the debugger!