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

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Wed Jan 1 19:42:42 UTC 2020


Hi all,


> If unwanted, do not use RunArray.

In general, to me, this seems not to be the best argument :)
I regard RunArray as a collection with optimized storage properties. I would definitely expect to work it analogously to a normal collection.
Just imagine something like SequenceableCollection >> #compressed which would convert the receiver to the subclass best matching the data set (even if it does not exist at the moment). In my opinion, RunArray should be an implementation detail.

> Having side effects in collect: slect: reject: blocks is more questionable.

Yes, it is questionabe, but with respect to the documentation comment, I tend to agree with Jakob ...

> Introduce a new selector for the optimized collect operation?

I also thought about this. Though, this would blow up the collection protocol even more ...

Best,
Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
Gesendet: Mittwoch, 1. Januar 2020 20:19:42
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Inbox: Collections-nice.869.mcz

Hi Christoph,


Le mer. 1 janv. 2020 à 19:48, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de<mailto:Christoph.Thiede at student.hpi.uni-potsdam.de>> a écrit :

Oops, Nabble rejected all my <raw>code</code> examples, sorry.


Was:

i := 0.

((RunArray new: 4 withAll: 42) collect: [:x | i := i + 1]) asArray. "#(1 1 1 1)""

vs.

i := 0.

(RunArray new: 4 withAll: 42) collect: [:x | i := i + 1] as: Array. "#(1 2 3 4)"

Best,
Christoph

Yes exactly, #collect: select: reject: replace: now have different behavior if we adopt those changes.
If unwanted, do not use RunArray.

Bag #collect: select: reject: could also behave like that.

Having side effects in do: blocks is OK.
Having side effects in collect: slect: reject: blocks is more questionable.
We use such side effects because we know that these methods are implemented with #do:, but it's not necessarily so.

I thought about #collect:as: and wondered if it should preserve iteration on each element or also act per run.
Since the intention is to transfer to another class, I think that element-wise loop is the least surprising.


________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org<mailto:squeak-dev-bounces at lists.squeakfoundation.org>> im Auftrag von Thiede, Christoph
Gesendet: Mittwoch, 1. Januar 2020 19:52 Uhr
An: squeak-dev at lists.squeakfoundation.org<mailto:squeak-dev at lists.squeakfoundation.org>
Betreff: Re: [squeak-dev] The Inbox: Collections-nice.869.mcz

Great, thanks for the enhancement!

Now we have got:


vs.


Would be great to align this. Is it necessary for RunArray >> do: to call
aBlock once per index?

I don't think so.
It's expected to have block with side effects for do:
We have (aRunArray values do:) or (aRunArray runsAndValuesDo:)


Best,
Christoph



--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200101/6986a977/attachment.html>


More information about the Squeak-dev mailing list