The standard does *not* support - a removeAll: a - [was: Re: [BUG]

Stephan Rudlof sr at evolgo.de
Sat Aug 31 16:19:14 UTC 2002


I wrote:
> Jesse Welton wrote:
> <snipped>
> 
>>However, I'm not sure how much weight to put on the fact that the
>>standard doesn't say anything about the argument to #removeAll: being
>>invariant during the call.  On a quick browse, I didn't see any
>>explicit caveats about the receiver of a #do: being modified by the
>>argument block, either.
> 
> 
>>Richard, would you say that the standard
>>requires #do: to work properly when the receiver is modified during
>>the iteration, as well?
> 
> 
> 
> What should be the semantics then?
> E.g.:
> 
> | a num |
> num _ 1.
> a := OrderedCollection with: num.
> a do: [:e | a size < 100 ifTrue: [a add: (num _ num+1)]].
> a
> 
> Should this give 100 elements in a (iterating over added elements, too)?
> Or 2 (copy semantics)? Like with
> 
> | a num |
> num _ 1.
> a := OrderedCollection with: num.
> a copy do: [:e | a size < 100 ifTrue: [a add: (num _ num+1)]].
> a
> 
> BTW: it gives 9...

This is one of the reasons, why I don't like to allow things like
  a removeAll: a
.
It is clear, that there has to be some iteration over the argument *while*
changing it. Allowing this would give the impression that the #do: above
could/should also work (resulting in 100 elements).
If this isn't enough: try implementing the functionality of the #do: above
for Sets...

As a general rule: Don't change a Collection while iterating over it.


Greetings,

Stephan

> 
> 
> Greetings,
> 
> Stephan
> 
> 
>>From the standard:
> NCITS J20 DRAFT	of ANSI Smalltalk Standard
> December, 1997 revision 1.9
> 
> 5.7.1.13
> Message:
> do: operation
> Synopsis
>   Evaluate operation with each element of the receiver.
> Definition: <collection>
>   For each element of the receiver, operation is evaluated with the element
> as the parameter.
> Unless specifically refined, the elements are not traversed in a particular
> order. Each element is visited exactly once. Conformant protocols may refine
> this message to specify a particular ordering.
> Parameters
>   operation	<monadicValuable>	uncaptured
> Return Values
>   UNSPECIFIED	
> Errors
>   If the elements of the receiver are inappropriate for use as arguments to
> operation.
> 
> 
>>-Jesse
>>
>>
>>
> 
> 
> 


-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3




More information about the Squeak-dev mailing list