Strange behaviour of abstract method
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
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 <mpaap@netcologne.de>
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.
Michael, On 31 Oct 2013, at 11:00, Michael Paap <mpaap@netcologne.de> 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
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
participants (3)
-
Bernat Romagosa -
Michael Paap -
Sven Van Caekenberghe