[Pharo-project] Collection extensions

Piers Cawley pdcawley at bofh.org.uk
Mon Jan 5 10:17:23 EST 2009

On Mon, Jan 5, 2009 at 3:06 PM, Stéphane Ducasse
<stephane.ducasse at inria.fr> wrote:
> On Jan 5, 2009, at 3:56 PM, Lukas Renggli wrote:
>>> I published to the inbox some cool collection extension methods that
>>> we use all the time in Moose.
>>> flatCollect:, collectAsSet:, and groupedBy:
>> I think Squeak already has far too many of these methods. I would
>> rather like to see them all removed, than new ones added. As an author
>> and maintainer of many Smalltalk framework I experience daily the pain
>> such methods cause, as they are inherently non-portable not only
>> between smalltalk dialects but even between users of exactly the same
>> image.
> But these ones are since they are coming from VisualWorks.
>> Let me give you an example: Seaside used
>> SequenceableCollection>>#pairsDo: in various places. The we got
>> complaints that almost all Smalltalk platforms already provide such a
>> method, but they all implement it entirely different. Some iterate
>> over the combinatorial pairs, some over the consecutive pairs, some
>> ignore an odd number of arguments, some raise an exception, etc. At
>> some point we learned that a famous company using Seaside has their
>> own proprietary override of this method. Today we use the ANSI
>> #to:do:. It is ugly, but it works everywhere as it is part of ANSI
>> Smalltalk.
> So why do we do pharo. Really. If everything as to be compatible with
> other
> smalltalk. Terrible.
> Can't we get smarter?
> Why can't we tag the methods with <notAnsi> and build a tool that
> check when you
> do a fill out. I do not write code to be portable to VisualWorks so?
>> I would prefer to have such extension methods separate from the core.
> Me not. Because then in a lot of places I will have to inline their
> body.

Would it not be possible to implement a macro refactoring at a package
level that walks the package looking for non ANSI compatible messages
sent to collections and suggests appropriate inlinings to make things
compliant (or at least flags up problematic methods). That way
implementers who use Pharo as their development platform can work with
the Pharo specific extensions as they develop, but can publish
variants of the code that are ANSI compliant.

No, I don't have the skills to implement such a thing, but I'm sure
they could be acquired.

More information about the Pharo-dev mailing list