On 9 March 2013 03:15, Colin Putney <colin at wiresong.com> wrote:
>
>
>
> On Fri, Mar 8, 2013 at 2:41 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>
>>
>> i making a prototype implementation right now.. so you can look and see.
>
>
> I think I understand what you're proposing, but I don't think you've
> explained why you think it's a good idea. The alternative, sending #value to
> the binding, is already implemented, works well and is supported by all the
> tools. What advantage does your idea have that makes it worth the effort?
>

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.

Then, i wonder, if such change is actually worth doing. Because if you
don't do lookup dynamically,
then there is no change.

But if you going to do a dynamic lookup, your binding will have to do
extra work by holding (lookup name and environment object), and so
your #value method will look like:

MyEnvBinding>>value

  ^ env lookupForName: name  "where name and env is inst vars"

and then , depending on implementation .. it will cost extra cycles to
do a lookup
but i bet you will end up having a Dictionary somewhere to which you
will send #at: message.
But think how many extra message sends you must perform in order to do a lookup
(especially in cases when you have a deeply nested namespace  hierarchies) .
So, at the end, you will pay much bigger price for accessing the
variable by its name dynamically.

In my case, the <special object> to which you sending #Name message is
an instance of Behavior,
which already holds a dictionary (method dictionary).. and lookup is
performed by VM,
you can chain those objects through <superclass> field so VM will do a
lookup visiting different namespaces..
Now think, how much faster it will be, especially with JIT and inline cache.
You sending a message, VM does lookup, you grab the result. done.

-- 
Best regards,
Igor Stasenko.