Smalltalk › Squeak › Squeak - Dev

#shouldBeImplemented vs #notYetImplemented

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Christoph Thiede

#shouldBeImplemented vs #notYetImplemented

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:

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

Carpe Squeak!

Bert Freudenberg

Re: #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 <[hidden email]> 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:

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

Christoph Thiede

Re: #shouldBeImplemented vs #notYetImplemented

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 <[hidden email]> im Auftrag von Bert Freudenberg <[hidden email]>
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 <[hidden email]> 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:

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

Carpe Squeak!

Chris Muller-3

Re: #shouldBeImplemented vs #notYetImplemented

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 <[hidden email]> 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 <[hidden email]> im Auftrag von Bert Freudenberg <[hidden email]>
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 <[hidden email]> 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:

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

Jakob Reschke

Re: #shouldBeImplemented vs #notYetImplemented

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> im Auftrag von Bert Freudenberg <[hidden email]>
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 <[hidden email]> 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:

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

Bert Freudenberg

Re: #shouldBeImplemented vs #notYetImplemented

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> im Auftrag von Bert Freudenberg <[hidden email]>
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 <[hidden email]> 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:

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

Jakob Reschke

Re: #shouldBeImplemented vs #notYetImplemented

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> im Auftrag von Bert Freudenberg <[hidden email]>
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 <[hidden email]> 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:

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