Adding methods in the Debugger

Alain Fischer mailinglist.fischer at bluewin.ch
Thu Feb 13 20:58:04 UTC 2003


Hi Andrew, Ned, Adam,

Amusing to see that there is interest for such a behavior of the 
debugger, I wrote a piece of code which makes the same thing a few days 
ago. And before I had time to release it, Ned and Adam have
implemented one. I think the two version could be complementary and must 
be merged.

When you use the contextual menul on a #doesNotUnderstand: of the 
context stack list you see
an additional menu with submenu representing the class and superclass of 
the context receiver.
You can then choose the wanted class and a stub method is compiled then 
the DNU context is replaced
with the compiled method.

Here is my version

-------------- next part --------------
A non-text attachment was scrubbed...
Name: DebugCreateMethods-AFi.1.cs
Type: application/text
Size: 3469 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030213/74188cc3/DebugCreateMethods-AFi.1.bin
-------------- next part --------------


Enjoy this new way to code in the debugger.
Alain


Le Jeudi 13 f?vrier 2003, ? 03:52 , Andrew P. Black a ?crit :

> At OOPSLA I took part in an XP-like design effort as part of Designfest.
> This was fun because not all of the participants were familiar with 
> Squeak, so those of us who were paired with those who were not, and got 
> to demonstrate some of the mouse's power.
>
> What we did was start by writing tests.  This amounted to designing the 
> interface that clients could use.  Of course, the tests would 
> immediately generate an error, because the messages that they sent were 
> not understood -- obviously, because the corresponding methods had not 
> yet been written.  We would then write the missing method, re-run the 
> test, and get a new error.  Eventually, all of the methods were in 
> place, and the test would fail.  Then we continued debugging, until it 
> passed.
>
> Programming in this absolutely test-driven manner was a new experience 
> for me, and it worked very well.  Normally, I try to keep track of what 
> methods need to be written in my head or on a 3x5 card; with this 
> methodology, I didn't have to.  It was always clear what to do next, 
> and one got a real sense of making progress.
>
> Afterwards, in discussing this experience with someone, I learned that 
> the process could be made even better.  The trick is to enhance the 
> debugger so that when a MNU occurs, it is possible to define the 
> missing method right there, in the debugger, and resume.  I imagine 
> that this makes the whole process smoother; after all, the debugger 
> knows exactly what method needs to be defined, and can offer a 
> hierarchy of possible classes where it could be located.
>
> My question is: has someone done this for Squeak?  For other Smalltalks?
>
> 	Andrew
>
>


More information about the Squeak-dev mailing list