2013/3/12 Bert Freudenberg <bert at freudenbergs.de>:
> On 2013-03-12, at 02:26, Colin Putney <colin at wiresong.com> wrote:
>
>> On Mon, Mar 11, 2013 at 5:59 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>
>>> No.  Its arguably a bug but a binding will print itself as the Symbol key.  So what's happening is that the binding for DateAndTime is printing itself as #DateAndTime.  So the problem is that the Decompiler is not mapping the sequence pushLiteral: aBinding, send #value back into an appropriate LiteralVariableNode instance.  The Decompiler needs to special-case this.
>>>
>> Yeah, that should probably be fixed. The new Alias bindings will generate #value sends, which I don't think we've used before. (We've used #value: for assignment to globals, but not #value for reads.)
>

Well, I used value sends for my experiments of auto and lazy
initialization of class variables
http://smallissimo.blogspot.fr/2011/08/lazy-initialization-of-shared-variable.html
so I can say it kind of works.

> Isn't #value too general to serve as a specially treated token in the decompiler? It might easily appear in code.
>
> I'd think it would be better if the compiler emitted a unique message selector that the decompiler could reliably recognize. Maybe #pvtValue, which cannot be used in regular code anyway?
>
> - Bert -
>

That's a good question.
If we want to be able to define different behaviors with delegation in
mind, pvtValue seems a bit restrictive.
Corolaries: how will the VM optimize the send (PIC, etc...)

Nicolas