Eliminating assignments and variable syntax (accessors)
Marcel Weiher
marcel at system.de
Mon Aug 2 20:04:30 UTC 1999
Yes, this is definitely one of the issues I alluded to in
>The compiler can compile implicit message sends either as real
>message sends or as direct variable access, depending on various
>factors. (This is deliberately vague).
and one of the reasons I presented it as a *rough sketch* and not
"the solution".
> From: agree at carltonfields.com
>
> Perhaps I'm stating the obvious, but isn't there a potential
problem here?
> In particular, let us consider:
>
> instvar := <expression>
>
> Presently, this unambiguously means munge instvar and replace it
with the
> answer to the expression. That's fine so far as it goes, and
we've discussed
> at length the upside/downside of using it in raw form.
>
> But sometimes we MUST be able to articulate precisely this
function. For
> example, in the accessor:
>
> instvar
>
> ^instvar
>
> and the setter:
>
> instvar: anExpression
>
> ^instvar := anExpression
>
> Clearly, if every reference to instvar is treated as a call to method
> instvar,
Well, one could argue that plain accessors are special enough that
they could be treated specially by the compiler, but it turns out
that this isn't necessary. What I described actually turns such
calls into direct access unless there is an accessor...
> and every "assignment" to instvar is treated as a recusive call to
> method instvar:, neither of the definitions above will serve,
resulting in
> infinite recursive regress. (Now that's inefficient!)
....and you could definitely argue that inside the definition of the
accessor, the accessor does not yet exist, so
instvar:newValue
newValue isOk ifTrue:
[instvar:newValue].
would actually work and not cause in infinite regress, although it
certainly would look a little peculiar. Maybe the way to look at it
would be to write this as
instvar:newValue
newValue isOk ifTrue:
[super instvar:newValue].
although that raises another couple of problems...
Marcel
More information about the Squeak-dev
mailing list
|