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

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Thu Jan 2 22:49:08 UTC 2020


> We have other selectors available for RunArray specific semantic, like aRunArray values do:, aRunArray runsAndValuesDo:


Side note: If you see any real use case for [aRunArray values do:], please make a forwarding selector #valuesDo: for it. I really don't want to encourage LoD violations. Alternatively, provide #runsAndValues as a dictionary? Hm ...
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
Gesendet: Donnerstag, 2. Januar 2020 22:45:13
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Inbox: Collections-nice.869.mcz



Le jeu. 2 janv. 2020 à 22:09, Jakob Reschke <forums.jakob at resfarm.de<mailto:forums.jakob at resfarm.de>> a écrit :
Am Do., 2. Jan. 2020 um 21:12 Uhr schrieb Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com<mailto:nicolas.cellier.aka.nice at gmail.com>>:
If we strictly adhere to this interpretation of method comment, detectMin: detectMax: detect:ifNone: and count: should also iterate on each and every element.
Do you agree that count: hardly benefits from such definition?

Instinctively I wanted to reply that the optimization in RunArray does not change the result of these operations contrary to collect: because they do not change elements, so equal elements could not suddenly become non-equal elements during the operation. But it got me thinking that I cannot imagine these usefully with side effects in the blocks... :-)

What about do: and inject:into: instead? Would you evaluate their blocks only once per run?

No.
It would mean changing the semantics.
I don't want to change the semantics, just the implementation.
We have other selectors available for RunArray specific semantic, like aRunArray values do:, aRunArray runsAndValuesDo:

Side effects in collect: and select: (and count: etc...) are border line.
Either we expect that those methods must enumerate exactly like do: in order to support side effects uniformely.
Your reaction perfectly  demonstrates that this can be a legitimate expectation.
Or we consider that the enumeration is implementation defined, as long as the methods maps, filter, (count etc...).
I think that RunArray has a greater value in itself if we adopt the later, but it's only my own opinion so far.

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


More information about the Squeak-dev mailing list