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