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
|