On 10 March 2013 06:47, Colin Putney <colin at wiresong.com> wrote:
>
>
>
> On Sat, Mar 9, 2013 at 6:48 AM, Igor Stasenko <siguctua at gmail.com> wrote:
>
>>
>> Well, maybe it's an overkill .. it is mainly about speed and reusing
>> VM's lookup mechanism
>> for searching a name over multiple scopes (when you have namespaces
>> with imports).
>>
>> On a first run, you will replace
>> "read value of <binding>" bytecode with " send #value to <binding>"
>> but that implies having a binding at compile time (you must lookup for
>> a name at compile time).
>> It also means that you won't change anything semantically: even though
>> you sending a message,
>> you still accessing the very same state which you bound early at compile
>> time.
>
>
> Right. The lookup happens at compile time. When the method is actually
> executed, we're just fetching the value from the binding we found at compile
> time. I don't see how that's going to be slow. In the most common case, a
> class reference, it's not even a message send, because we have a dedicated
> bytecode. For global variables, it'll be two message sends: we send #value
> to the alias binding, which then sends #value on to the canonical binding in
> the environment's "contents" dictionary.
>

okay, so as i understood, every namespace will have a set of own alias bindings
which can point to some "real" binding..
and then when things need to be changed, you have to change those
aliases instead of recompiling methods.
And only if method/class goes to different namespace you need to
recompile it, to rewire code with different aliases.

Yes, that's quite simple.

>> Then, i wonder, if such change is actually worth doing. Because if you
>> don't do lookup dynamically,
>> then there is no change.
>
>
> Sure there is. We still bind names at compile time, but we have changed the
> way names are resolved.
>

> Colin

-- 
Best regards,
Igor Stasenko.