On 01.10.2011, at 18:33, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:

> 2011/10/1 Bert Freudenberg <bert at freudenbergs.de>:
>> 
>> On 30.09.2011, at 13:05, Nicolas Cellier wrote:
>> 
>>> 2011/9/30 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
>>>> 2011/9/30 Bert Freudenberg <bert at freudenbergs.de>:
>>>>> 
>>>>> On 29.09.2011, at 19:22, Rodney Polkinghorne wrote:
>>>>> 
>>>>>> Dear list
>>>>>> 
>>>>>> I wanted an array that lazily initialized elements 1 to n when you
>>>>>> asked for the nth one.  So I ran something like:
>>>>>> 
>>>>>> SequenceableCollection variableSubclass #Foo ...
>>>>>> 
>>>>>> When I started a workspace, and tried Foo new: 10, my image hung.
>>>>>> 
>>>>>> Eventually, I found the problem.  The workspace tried to print the
>>>>>> answered instance, which resulted in it being sent a do: message to
>>>>>> print its elements.  This ran the method
>>>>>> 
>>>>>> SequenceableCollection>>do: aBlock
>>>>>>       1 to: self size do:
>>>>>>               [:index | aBlock value: (self at: index)]
>>>>>> 
>>>>>> which ran
>>>>>> 
>>>>>> Collection>>size
>>>>>>       | tally |
>>>>>>       tally := 0.
>>>>>>       self do: [:each | tally := tally + 1].
>>>>>>       ^ tally
>>>>>> 
>>>>>> which sent do:, which sent size, which ...
>>>>>> 
>>>>>> Is this considered a bug, or a learning experience for new players?
>>>>> 
>>>>> The latter. You should not instantiate an abstract class. I don't think there is much that could be done about this.
>>>>> 
>>>>> - Bert -
>>>>> 
>>>> 
>>>> But Foo is a concrete class from Rodney, not Abstract.
>> 
>> No, it's still abstract since he did not override any methods.
>> 
>>>> Generally, if the subclass must implement a method, it is expressed
>>>> with an abstract implementation in the upper level
>>>>    ^self subclassResponsibility
>>>> 
>>>> Here, the subclass must implement a message, either #do: or #size but
>>>> there is no explicit guidance.
>>>> Personnally I consider this as very bad kernel code if not a bug.
>>>> Does any subclass really use Collection>>size ?
>>> 
>>> OK, I just opened an image to check and only one does: LinkedList.
>>> I suggest moving  Collection>>size implementation to LinkedList, and
>>> replace it with a subclassResponsibility.
>>> 
>>> Nicolas
>> 
>> That would be make the intention more clear, agreed.
>> 
>> - Bert -
>> 
> 
> Eliot objected that #do: is already abstract at Collection level, so
> #size does not have to be.
> An alternative would be to re-implement
> Sequenceable>>size
>    ^subclassResponsibility
> 
> What do others think ?

I thought that's what you meant :)

Yes, size should be subclass responsibility only for SequenceableCollections, not Collection. 
> 


- Bert -