I have another idea:

In the Traits paper (IIRC where I first saw this), required methods are
marked with shouldBeImplemented. If you would use notYetImplemented
instead, it would look like the method was not yet implemented in the
trait. In fact it is not supposed to be implemented in the trait. Instead
classes using the trait are supposed to supply an implementation. You
cannot use subclassResponsibility in the trait either because then classes
using the trait would look like a subclass of them should implement the
method, but the class itself should do it.

Ideally, shouldBeImplemented in the trait method would somehow become
notYetImplemented in a class that has the trait. But this would be magic.
;-)

If you just omit the required methods from a trait and rely on the test
suite of using classes to find the missing ones, the selector issue does
not arise, of course.


Am Di., 4. Feb. 2020 um 22:48 Uhr schrieb Bert Freudenberg <
bert at freudenbergs.de>:

> 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/20200208/14aea093/attachment.html>