[squeak-dev] The Inbox: Collections-nice.869.mcz

Jakob Reschke forums.jakob at resfarm.de
Wed Jan 1 20:02:34 UTC 2020

Am Mi., 1. Jan. 2020 um 20:44 Uhr schrieb Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:

> Yes, indeed, this is a slight shift of semantics.

One could also call it not implementing the interface properly or breaking
the contract ;-)

> But RunArray are essentially unused (just to store Text attributes).
> They make sense only for optimization.
> So they can have their own semantic, bended to their own purpose.

Disregarding interfaces and contracts, yes. But it may surprise someone in
the future.

> It's just that we need to comment a bit more those methods.

I brought this up during a naming discussion in VMMaker some time ago: some
people don't read the documentation and just rely on their expectations. It
might be foolish to do so, but expectations can be justified and allow you
to work more efficiently. I wouldn't like to re-check the implementation of
#collect: for every new Collection subclass that comes along, in particular
if I don't want to look it its implementation.

> If we don't want this behavior, then we probably don't want to use a
> RunArray

Sometimes you don't know what kind of collection you get to #collect: from.

> Introducing a different selector would mean implementing it in other
> collection too.

Not necessarily. Set also does not understand #before:, you must use a
SequenceableCollection if you want it. Conversely if you knowingly use a
RunArray (as in Text) and you want to exploit the optimization for the
iteration blocks, you could use the new selector(s).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200101/a091d50d/attachment.html>

More information about the Squeak-dev mailing list