[squeak-dev] #shouldBeImplemented vs #notYetImplemented

Chris Muller asqueaker at gmail.com
Wed Jan 29 02:24:09 UTC 2020

Hi Christoph,

#subclassResponsibility is part of standard Smalltalk.

I think #notYetImplemented and #shouldBeImplemented are "code markers"
indicating a to-do item and, yes, do seem a bit too ambiguous.  Perhaps we
should replace all #notYetImplemented with #shouldBeImplemented...

On Sat, Jan 25, 2020 at 7:21 AM Thiede, Christoph <
Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:

> Thanks Bert, but then, what is the difference between #shouldBeImplemented
> and #subclassResponsibility?
> And if I understand you correctly, the method stub created by a debugger
> should rather insert a #notYetImplemented than a #shouldBeImplemented,
> shouldn't it?
> Best,
> Christoph
> ------------------------------
> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Bert Freudenberg <bert at freudenbergs.de>
> *Gesendet:* Samstag, 25. Januar 2020 01:13:10
> *An:* The general-purpose Squeak developers list
> *Betreff:* Re: [squeak-dev] #shouldBeImplemented vs #notYetImplemented
> If a class has a method sending #shouldBeImplemented, then subclasses are
> supposed to override that method, without modifying the superclass method.
> It basically marks that class as abstract.
> In contrast, #notYetImplemented indicates that the method itself should be
> modified, replacing the #notYetImplemented send with the actual code.
> - Bert -
> On Fri, Jan 24, 2020 at 7:10 AM Thiede, Christoph <
> Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
>> Hi all,
>> what exactly is the intended difference between #shouldBeImplemented and
>> #notYetImplemented? It feels a bit confusing.
>> I have always used #shouldBeImplemented only because it is predefined by
>> the Debugger.
>> But today I met #notYetImplemented and now wonder which one I should use:
>> <http://www.hpi.de/>
>>    - Both are detected by the debugger
>>    - But #notYetImplemented has its own subclass implementation of
>>    NotImplemented which handles #receiverClass and #selector. I like this, it
>>    has a bit more object-orientation appeal.
>>    - The names don't give me an indication to any semantical difference
>>    - They are not in the same message category of Object at all!
>>    - #shouldBeImplemented raises a specific error message, while that
>>    one of #notYetImplemented is generic and less precise
>>    - But why does the #shouldBeImpleemented message mention "or a
>>    superclass should implement"? Given the subclass Bar of the
>>    superclass Foo and I compile '#baz ^self shouldBeImplemented' on Bar. Why
>>    should this indicate that #baz might have to implemented on Foo instead?
>>    - Btw, we also have Object >> #required, which looks more Trait
>>    specific. Is it a problem that Tools-Debugger depends on Traits via this
>>    selector?
>> However, I think we might have some heterogenic duplication here, or at
>> least miss any documentation of the differences. Can you tell me more about
>> the history of both selectors? Should we try to merge them?
>> Best,
>> Christoph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200128/2dbdeeb0/attachment.html>

More information about the Squeak-dev mailing list