[squeak-dev] #shouldBeImplemented vs #notYetImplemented

Bert Freudenberg bert at freudenbergs.de
Tue Feb 4 21:47:42 UTC 2020


I actually confused subclassResponsibility and shouldBeImplemented - not
actually looking at an image.

As Chris wrote, subclassResponsibility is standard. And I don't remember
where shouldBeImplemented came from ... the oldest timestamp I found was by
"AFi"?

I like notYetImplemented better, FWIW.

- Bert -

On Tue, Jan 28, 2020 at 11:07 PM Jakob Reschke <forums.jakob at resfarm.de>
wrote:

> I assume most people coming from other languages will likely search for
> "not yet implemented" when they want to leave such a marker.
>
> Chris Muller <asqueaker at gmail.com> schrieb am Mi., 29. Jan. 2020, 03:24:
>
>> 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/20200204/ca4a561b/attachment-0001.html>


More information about the Squeak-dev mailing list