Strange behaviour of abstract method

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Strange behaviour of abstract method

Michael Paap-2
Hello list,

in our OOP course we noticed some behaviour of an abstract method, which
I cannot explain. Maybe you can help me:

If I do the following

     SequenceableCollection new add: 123

I would expect an Error. The method add: is not implemented in
SequenceableCollectionbut inherited from collection, where it's only
statement is

     self subclassResponsibility

But in reality, Pharo seems to enter an endless loop, consuming more and
more memory.

Can someone please explain to me, what happens here?

Greetings,
Michael

Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour of abstract method

Bernat Romagosa
Just tried in Pharo 1.4, 2.0 and 3.0. It fails in all of them.

The error doesn't happen when sending #add: though. Try doing SequenceableCollection new and the same thing will happen.


2013/10/31 Michael Paap <[hidden email]>
Hello list,

in our OOP course we noticed some behaviour of an abstract method, which I cannot explain. Maybe you can help me:

If I do the following

    SequenceableCollection new add: 123

I would expect an Error. The method add: is not implemented in SequenceableCollectionbut inherited from collection, where it's only statement is

    self subclassResponsibility

But in reality, Pharo seems to enter an endless loop, consuming more and more memory.

Can someone please explain to me, what happens here?

Greetings,
Michael




--
Bernat Romagosa.
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour of abstract method

Sven Van Caekenberghe-2
In reply to this post by Michael Paap-2
Michael,

On 31 Oct 2013, at 11:00, Michael Paap <[hidden email]> wrote:

> Hello list,
>
> in our OOP course we noticed some behaviour of an abstract method, which I cannot explain. Maybe you can help me:
>
> If I do the following
>
>    SequenceableCollection new add: 123
>
> I would expect an Error. The method add: is not implemented in SequenceableCollectionbut inherited from collection, where it's only statement is
>
>    self subclassResponsibility
>
> But in reality, Pharo seems to enter an endless loop, consuming more and more memory.
>
> Can someone please explain to me, what happens here?
>
> Greetings,
> Michael

Obviously, abstract classes should not be instanciated, but in teaching this is bound to happen.

Now, the actual error happens in the environment (debugger, inspector, printString mechanisms): they see a collection and try to work with it, since it is an incomplete/degenerate one, things break/loop.

The following does work for example:

  SequenceableCollection new isCollection.

The question is: should there be an explicit error message when an abstract class is instanciated, is that even possible ?

Sven


 


Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour of abstract method

Michael Paap-2
Am 31.10.2013 11:24, schrieb Sven Van Caekenberghe:

> Obviously, abstract classes should not be instanciated,

This is of course known.

> Now, the actual error happens in the environment (debugger,
> inspector, printString mechanisms): they see a collection and try to
> work with it, since it is an incomplete/degenerate one, things
> break/loop.

Ok. This explains, why just "doing"

     SequenceableCollection new

is ok, while "printing" causes problems. Thank you for your explnation.

> The question is: should there be an explicit error message when an
> abstract class is instanciated, is that even possible ?

This may be difficult, because the instantiation of a not abstract
subclass normally /is/ an instantiation of the abstract super class,
isn't it?

And in Smalltalk we have no concept of abstractness in the language
itself, but only by convention.

Greetings,
Michael