Hi Jakob,


Le mer. 1 janv. 2020 à 20:19, Jakob Reschke <forums.jakob at resfarm.de> a
écrit :

> Hi Nicolas,
>
> Am Mi., 1. Jan. 2020 um 19:48 Uhr schrieb Thiede, Christoph <
> Christoph.Thiede at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200101/b7ae8075/attachment.html>