On 9 March 2013 03:15, Colin Putney colin@wiresong.com wrote:
On Fri, Mar 8, 2013 at 2:41 PM, Igor Stasenko siguctua@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.