<br><br><div class="gmail_quote">On Tue, Mar 12, 2013 at 11:52 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 2013-03-12, at 15:59, Colin Putney <<a href="mailto:colin@wiresong.com">colin@wiresong.com</a>> wrote:<br>
<br>
> On Tue, Mar 12, 2013 at 3:17 AM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>
><br>
> Isn't #value too general to serve as a specially treated token in the decompiler? It might easily appear in code.<br>
><br>
> AFAICT, the decompiler should special case a send of #value *to a binding*, not just any send of #value. There's no way to refer directly to a binding with regular Smalltalk code, right?<br>
<br>
</div></div>Ah. Well, I guess it would be the first time the decompiler behavior depends on the *kind* of literal stored, but then, maybe that's not so bad. Being able to just use #value would be nice indeed.<br></blockquote>
<div><br></div><div>The point is that one can't mention variable bindings in code directly. There's no literal denotation of a binding; bindings (Associations and/or VariableBindings et al) are not literals; the only way to introduce a binding into the bytecode is via a global variable reference. So if the Decompiler finds a binding on the decompilation stack it knows that that is a variable reference, and hence that "aBinding value" must be a variable dereference.</div>
<div><br></div><div>And of course, any other reference to a binding in code will be a send, e.g. self classPool associationAt: #Foo will appear to the debugger as a send of #associationAt:, not as a VariableNode for #Foo.</div>
</div>-- <br>best,<div>Eliot</div>