#subclassResponsibility (was Re: [squeak-dev] Everyone's talking about debuggers these days)

> Inline, briefly.
>
> On Jan 25, 2013, at 1:55 PM, Frank Shearar <[hidden email]> wrote:
>
>> By "stub out stuff" do you mean "write a stub test case with self
>> assert: false"? *raises hand*
>
> Actually, I do that when I'm feeling responsible, as in I-might-want-to-use-this-more-than-once. More often though, I'm dinking around on Project Euler and plan to throw my code away, in which case I just paste in "self break."
>
>> Annoyingly, defining a #subclassResponsibility method destroys my
>> flow: the debugger won't, obviously, prompt you for that "create
>> method" button I love so much. (Hm, could one restore that with a
>> SubclassResponsibilityException that the debugger can catch?)
>
> I'm not sure what the right way to do that would be, but I feel your pain. Try it?

> -----Original Message-----
> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Frank Shearar
>
> On 25 January 2013 22:29, Casey Ransberger <[hidden email]>
> wrote:
> > Inline, briefly.
> >
> > On Jan 25, 2013, at 1:55 PM, Frank Shearar <[hidden email]>
> wrote:
> >
> >> By "stub out stuff" do you mean "write a stub test case with self
> >> assert: false"? *raises hand*
> >
> > Actually, I do that when I'm feeling responsible, as in

>
>
> > -----Original Message-----
> > From: [hidden email] [mailto:squeak-dev-
> > [hidden email]] On Behalf Of Frank Shearar
> >
> > On 25 January 2013 22:29, Casey Ransberger <[hidden email]>
> > wrote:
> > > Inline, briefly.
> > >
> > > On Jan 25, 2013, at 1:55 PM, Frank Shearar <[hidden email]>
> > wrote:
> > >
> > >> By "stub out stuff" do you mean "write a stub test case with self
> > >> assert: false"? *raises hand*
> > >
> > > Actually, I do that when I'm feeling responsible, as in
> I-might-want-to-use-this-
> > more-than-once. More often though, I'm dinking around on Project Euler and
> > plan to throw my code away, in which case I just paste in "self break."
> > >
> > >> Annoyingly, defining a #subclassResponsibility method destroys my
> > >> flow: the debugger won't, obviously, prompt you for that "create
> > >> method" button I love so much. (Hm, could one restore that with a
> > >> SubclassResponsibilityException that the debugger can catch?)
> > >
> > > I'm not sure what the right way to do that would be, but I feel your
> pain. Try
> > it?
> >
> > So actually the UI part is really easy, thanks to Debugger >>
> > #buildNotifierWith:label:message:. I now have a nice Create button, it
> calls the
> > correct method... but I'm a bit stumped. I can record in the call of "self
> > subclassResponsibility" the class and selector that needs implementing
> (stored in
> > a SubclassResponsibilityError), and this causes the debugger to pop up...
> but I
> > don't know how to get a handle on the SubclassResponsibilityError itself
> to find
> > out what to do.
> >
> > Any ideas? (I've scratched around a fair bit with exception handling and
> the
> > Debugger, but this is one step beyond me right now.)
>
> Hi Frank,
>
> I'm not sure I understand what you are having trouble with, but if I needed
> to build a specific handler for subclassResponsibility I would create a new
> class:
>
> Error subclass: #SubclassResponsibilityError
> ...
>
> You could then change
>
> Object>> subclassResponsibility
> "This message sets up a framework for the behavior of the class'
> subclasses.
> Announce that the subclass should have implemented this message."
>
> self error: 'My subclass should have overridden ', thisContext
> sender selector printString
>
> To:
>
> Object>> subclassResponsibility
> "This message sets up a framework for the behavior of the class'
> subclasses.
> Announce that the subclass should have implemented this message."
> SubclassResponsibilityError new
> parentClass: thisContext sender;
> methodSelector: thisContext sender selector printString;
> signal: 'My subclass should have overridden ', thisContext
> sender selector printString.
>
> Now you can build a handler to do whatever you want it to do.  That will
> give you a specific error object for this type of error.  
> Does that answer your question?
>
> All the best,
>
> Ron Teitelbaum
>
> >
> > frank
> >
>
>

>
>
>> -----Original Message-----
>> From: [hidden email] [mailto:squeak-dev-
>> [hidden email]] On Behalf Of Frank Shearar
>>
>> On 25 January 2013 22:29, Casey Ransberger <[hidden email]>
>> wrote:
>> > Inline, briefly.
>> >
>> > On Jan 25, 2013, at 1:55 PM, Frank Shearar <[hidden email]>
>> wrote:
>> >
>> >> By "stub out stuff" do you mean "write a stub test case with self
>> >> assert: false"? *raises hand*
>> >
>> > Actually, I do that when I'm feeling responsible, as in
> I-might-want-to-use-this-
>> more-than-once. More often though, I'm dinking around on Project Euler and
>> plan to throw my code away, in which case I just paste in "self break."
>> >
>> >> Annoyingly, defining a #subclassResponsibility method destroys my
>> >> flow: the debugger won't, obviously, prompt you for that "create
>> >> method" button I love so much. (Hm, could one restore that with a
>> >> SubclassResponsibilityException that the debugger can catch?)
>> >
>> > I'm not sure what the right way to do that would be, but I feel your
> pain. Try
>> it?
>>
>> So actually the UI part is really easy, thanks to Debugger >>
>> #buildNotifierWith:label:message:. I now have a nice Create button, it
> calls the
>> correct method... but I'm a bit stumped. I can record in the call of "self
>> subclassResponsibility" the class and selector that needs implementing
> (stored in
>> a SubclassResponsibilityError), and this causes the debugger to pop up...
> but I
>> don't know how to get a handle on the SubclassResponsibilityError itself
> to find
>> out what to do.
>>
>> Any ideas? (I've scratched around a fair bit with exception handling and
> the
>> Debugger, but this is one step beyond me right now.)
>
> Hi Frank,
>
> I'm not sure I understand what you are having trouble with, but if I needed
> to build a specific handler for subclassResponsibility I would create a new
> class:
>
> Error subclass: #SubclassResponsibilityError
> ...
>
> You could then change
>
> Object>> subclassResponsibility
>         "This message sets up a framework for the behavior of the class'
> subclasses.
>         Announce that the subclass should have implemented this message."
>
>         self error: 'My subclass should have overridden ', thisContext
> sender selector printString
>
> To:
>
> Object>> subclassResponsibility
>         "This message sets up a framework for the behavior of the class'
> subclasses.
>         Announce that the subclass should have implemented this message."
>         SubclassResponsibilityError new
>                 parentClass: thisContext sender;
>                 methodSelector: thisContext sender selector printString;
>                 signal: 'My subclass should have overridden ', thisContext
> sender selector printString.
>
> Now you can build a handler to do whatever you want it to do.  That will
> give you a specific error object for this type of error.
> Does that answer your question?
>
> All the best,
>
> Ron Teitelbaum