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

Jesse Welton jwelton at pacific.mps.ohio-state.edu
Fri Aug 30 18:53:49 UTC 2002


Stephan Rudlof wrote:
> [...]
> Since we have an 'uncaptured' parameter, the receiver *has* *to* never
> retain a reference to the parameter, directly or indirectly, as a result of
> this message.
> 
> Further: The parameter *is* the receiver in the case of
>     a removeAll: a
> . Has this receiver a direct reference to itself? I don't think so.
> But the *coupling* between receiver and parameter here is much stronger -
> identity! - than a mere reference. And the intent of the requirement here -
> as *I* read the standard - has been to have *no* coupling between parameter
> and receiver here.

This interpretation is clearly unreasonable.  I can see how one might
reasonably interpret the identity coupling as a sort of indirect
reference (though I suspect that what is meant instead is a reference
chain), but you're ignoring the very important clause, "as a result of
this message."  This coupling is not a result of the message at all.
Furthermore, consider the following:

  a := OrderedCollection with: 1.
  b := OrderedCollection with: 1 with: a.
  b removeAll: a.

I would certainly hope that any reasonable programmer would consider
this perfectly sensible, and should remove 1 from b, leaving it with
the single element a.  This is a direct reference that your reading of
the standard would require to be illegal.  Fortunately, since it is
clear that this reference is not a result of sending #removeAll:, it
is, in fact, permitted by the standard.


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?

-Jesse




More information about the Squeak-dev mailing list