Hi Jakob,
Le mer. 1 janv. 2020 à 20:19, Jakob Reschke forums.jakob@resfarm.de a écrit :
Hi Nicolas,
Am Mi., 1. Jan. 2020 um 19:48 Uhr schrieb Thiede, Christoph < Christoph.Thiede@student.hpi.uni-potsdam.de>:
i := 0.
((RunArray new: 4 withAll: 42) collect: [:x | i := i + 1]) asArray. "#(1 1 1 1)""
This one is broken, isn't it? A RunArray is still a collection of
elements and the comment of collect: in Collection states:
Evaluate aBlock *with each of the receiver's elements* as the argument.
- Collect the resulting values* into a collection like the receiver.
Answer the new collection. [emphasis mine]
Yes, indeed, this is a slight shift of semantics.
But RunArray are essentially unused (just to store Text attributes). They make sense only for optimization. So they can have their own semantic, bended to their own purpose.
It's just that we need to comment a bit more those methods. If we don't want this behavior, then we probably don't want to use a RunArray
IMO the storage optimization of RunArray should not affect the meaning of its operations. The intermediary RunArray in the code above should also contain 1, 2, 3, 4, even though it defeats the optimization.
We have different classes with different trade offs and different
behaviors. So, if possible, a common behavior is
Introduce a new selector for the optimized collect operation?
I have used such RunArray extensively in VW for storing time series with
many repeated values. In case when the ratio of repetition was too low, I used raw Array, because RunArray would just spoil space and time. Introducing a different selector would mean implementing it in other collection too.
So, yes, that would be a possible way, but I don't think that's the optimal way.
Kind regards,
Jakob