On 17 November 2012 09:12, Camillo Bruni <camillobruni@gmail.com> wrote:
This is what Pinocchio had, resolving classes was done by looking them up in the current environment (so basically the Class name is just a code macro). This way we could add simple class scopes without too much effort.
I guess that would make the following code example a bit more complicated:
oldDictClass := Dictionary. Dictionary := SmallDictionary.
dict := Dictionary new.
Dictionary := oldDictClass
self assert: (dict isKindOf: SmallDictionary).
why complicated? and you need is to translate <global> to: self class environmentAt: #<global> and <global> := value to self class environmentAt: #<global> put: value. this is very simple to do.
but this is a rather bad feature in my eyes ;)
globals is not good, i agree.. but if you think about them as 'anything which you need to access outside direct method scope', then you need it and it is not bad idea at all. To me, there's no much difference between global vars or class/pool vars. The main dividing line , imo is the method scope: if variable are not defined in scope of method itself (temps, arguments etc) then it should be delegated to class in order to resolve it (yes, including ivars). The class then can figure, if such name is 'visible' in its scope, as well as provide a ways to access it, by instructing encoder to inject appropriate AST nodes, i.e. 'macro-expanding accessors' to these variables. This could lead to some limitations, of course, because of late-bound semantics, you won't be able to decompile the method's bytecode and show the source code which accessing variable 'Foo', because it will decompile to message send(s). But that is IMO not a big deal. And to mitigate the overhead of late-binding, we can use literals (Foo->value) as cache: class can decide that in order to access value of variable named 'Foo', a compiler should produce following: (<Foo binding literal>) ifNil: [ <Foo binding literal> := self class environmentAt: #Foo ] like that, once cache filled, the overhead can be reduced to simple nil check. Similar approach is to just put a special 'binding' object into method's literal, and then simply send #value, or #value: message to it for accessing its value. The semantics of getting/setting the value then can be encapsulated inside of behavior of this 'binding' object(s). And this even friendlier to decompiler: you can simply check if given literal is special kind of 'binding object', and then decompile it appropriately, as well as you don't need to instruct compiler to encode complex ASTs for accessing the literal value.
On 2012-11-17, at 07:24, Fernando Olivero <fernando.olivero@usi.ch> wrote:
I love Marcus idea, classes aren't globals any more, and to access them is simply another message send to a receiver: the environment. ( like the lobby in Self ) .
Fernando
On Sat, Nov 17, 2012 at 8:56 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
The alternative to the current scheme would be to not hard-code the class at all in the method at compile time.
Instead of looking up the class and compiling the shared literal association, we could compile a message send to the current environment.
self class environment at: #NameOfClass
And it should be noted that this could be evaluated at Jit-compile time... the same is true for ivar offsets. There is no reason why these should be visible at the image level. The image could talk about names and let the runtime translator infrastucture do the lookups needed for making a static version that is fast.
Yes I would like to measure that too. My benchmarks were to measure the worse case where we have to manually update the methods each time the class is modified.
-- Best regards, Igor Stasenko.