[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
|