|
Re: The standard does *not* support - a removeAll: a - [was: Re: [BUG]: msg#01401lang.smalltalk.squeak.general
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@xxxxxxxxx) "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
|
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | Re: ICFP 2002 entry?, Randal L. Schwartz |
|---|---|
| Next by Date: | Re: The standard does *not* support - a removeAll: a - [was: Re: [BUG] Collection>>removeAll:], Andrew C. Greenberg |
| Previous by Thread: | Re: The standard does *not* support - a removeAll: a - [was: Re: [BUG], Stephan Rudlof |
| Next by Thread: | Re: The standard does *not* support - a removeAll: a - [was: Re: [BUG] Collection>>removeAll:], Andrew C. Greenberg |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |