On Sat, Oct 1, 2011 at 9:54 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> 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.
>

and if so this is tricky:
    SequenceableCollection withAllSubclasses select: [:c| (c
whichClassIncludesSelector: #size) == Collection]
    => an OrderedCollection(SequenceableCollection LinkedList Semaphore)

So if added as a subclass responsibility in SequenceableCollection it must
be implemented in LinkedList and Semaphore.

>
>
>
> - Bert -
>



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20111002/62235182/attachment.htm