[squeak-dev] Pending inbox items: #removeAll and #flatten vs. #flattened

Hi -

There are currently some items in the inbox that I'm not qualified to
deal with. One is Collections-klub.131.mcz that has various
implementations of #removeAll and seem to partly conflict with the
recently added implementations.

Nicolas - since you took the lead on removeAll, can I ask you to review
and merge it as appropriate (it looks like there are some specialized
implementations of #removeAll that may or may not be useful; it would be
good if you could check that).

Secondly, there seem to be competing implementations of #flatten vs.
#flattened. I'm wondering if anyone wants to take a lead on a discussion
/ decision on the matter. My feeling is simpler is better but I'm not a
heavy user of fancy collection methods so I don't feel qualified to make
a call. If we don't find anyone to lead the discussion I'll move the
packages to treated and declare the issue as "resolved by status quo" ;-)

Cheers,
   - Andreas

On Wed, Sep 16, 2009 at 08:32:51PM -0700, Andreas Raab wrote:
> Secondly, there seem to be competing implementations of #flatten vs.  
> #flattened. I'm wondering if anyone wants to take a lead on a discussion  
> / decision on the matter.
Looking at Collections-klub.130 I think I prefer its #flattened
implementation over mine with #flatten. I'd definetely like to see
it included.

--
Regards,
Tim

2009/9/17 Andreas Raab <[hidden email]>:
> Nicolas - since you took the lead on removeAll, can I ask you to review and
> merge it as appropriate (it looks like there are some specialized
> implementations of #removeAll that may or may not be useful; it would be
> good if you could check that).
>

OK, some extensions are good and I uploaded them.

Some others are conflicting and I did not upload them.
They are good too: the main difference is that klub preserves the
array of (OrderedCollection/Set/WeakSet) by using atAllPut: nil, while
I created a new one.
My implementation is a little cheaper for small/medium collections,
but klub's might perform better for huge ones (less pressure on
garbage collector). What do you think ?

Not enough Collection subclasses are tested. Someone should write more
test because ...

Cheers

Hi!

On Thu, 17 Sep 2009, Nicolas Cellier wrote:

The idea was to give the garbage collector less work. We found that
#atAllPut: is pretty fast for the job. It would be good to know how the
current (and the new) garbage collector can handle these. We assumed that
#removeAll will mostly be sent to "old" objects, so AFAIK only a full gc
can get rid of the thrown away collections with the current garbage collector.

> Not enough Collection subclasses are tested. Someone should write more
> test because ...

Yes, more tests would be nice. :)

Cheers,
Levente

Nicolas Cellier wrote:
> 2009/9/17 Andreas Raab <[hidden email]>:
>> Nicolas - since you took the lead on removeAll, can I ask you to review and
>> merge it as appropriate (it looks like there are some specialized
>> implementations of #removeAll that may or may not be useful; it would be
>> good if you could check that).
>
> OK, some extensions are good and I uploaded them.

Thanks!

> Some others are conflicting and I did not upload them.
> They are good too: the main difference is that klub preserves the
> array of (OrderedCollection/Set/WeakSet) by using atAllPut: nil, while
> I created a new one.
> My implementation is a little cheaper for small/medium collections,
> but klub's might perform better for huge ones (less pressure on
> garbage collector). What do you think ?

I think it probably doesn't matter for now. If there is a real
performance difference someone will point it out and discuss it in
detail. For now I'd go with the simplest solution.

> Not enough Collection subclasses are tested. Someone should write more
> test because ...

Heh, heh. Yes, indeed.

Cheers,
   - Andreas