[squeak-dev] The Inbox: Collections-nice.869.mcz
nicolas.cellier.aka.nice at gmail.com
Thu Jan 2 21:45:13 UTC 2020
Le jeu. 2 janv. 2020 à 22:09, Jakob Reschke <forums.jakob at resfarm.de> a
> Am Do., 2. Jan. 2020 um 21:12 Uhr schrieb Nicolas Cellier <
> 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?
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
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...
More information about the Squeak-dev