On 3 sept. 2014, at 11:42, Clément Bera <[email protected]> wrote:

> Hello guys,
> 
> I was looking into the OrderedCollection protocols recently to see how well 
> the sista optimizer perform with it methods, and I realized that this is 
> completely broken.
> 
> For example:
> 
> col := #(1 2 3 4 5) asOrderedCollection.
> col do: [ :elem | elem trace .
>       elem < 4 ifTrue: [ col add: col size + 1 ]].
> 
> => '12345678'
> 
> However:
> 
> col := #(1 2 3 4 5) asOrderedCollection.
> col collect: [ :elem | elem trace .
>       elem < 4 ifTrue: [ col add: col size + 1 ]].
> 
> => '12345'
> 
> This means that #do: and #reverseDo: iterate over all the elements of the 
> collection,*including* the ones that you are adding while iterating over the 
> collection, whereas all the other OrderedCollection protocols, such as 
> #collect:, #select:, iterates over all the elements of the collection, 
> *excluding* the ones you are adding while iterating over the collection.
> 
> Marcus argued that one should not edit a collection while iterating over it, 
> however this point is not valid as the World menu relies on this feature, 
> using #do: to iterate over the elements of the OrderedCollection including 
> the one it is adding while iterating over the collection. Changing the 
> implementation makes the world menu display half of its items.
> 
> I don't like this difference because it is inconsistent. For example, 
> refactoring a #do: into a #collect: can simply not work because they do not 
> iterate over the same elements if you are editing the collection while 
> iterating over it.
> 
> In VW, the protocols are consistent and iterating over a collection never 
> iterates over the elements one is adding while iterating over it. Therefore, 
> I believe most frameworks should expect this behavior (at least the ones 
> cross smalltalk) which sounds the most correct.
> 
> I think we should fix the world menu implementation and make the protocols 
> consistent. Alternatively, we can let VW be a much more consistent Smalltalk 
> environment than Pharo. What do you think ?


The thing is to find alternative implementations that are efficient enough (no 
copy). Maybe we can get some inspirations from VW for that (how do they do 
BTW?).  
You should also check with other kinds of collection because they may act 
differently than OrderedCollection. 
So in the end it depends on the amount of effort needed to make all collections 
consistent with this new requirement and on the resulting overhead.
If it's too much, I think that following the old advice "don't modify a 
collection while iterating it" is enough. If one really needs to do such kind 
of things he should consider an alternative design like using a zipper for 
example.

Camille

> 
> Clement
> 


Reply via email to