On 18 November 2012 21:53, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Nov 18, 2012, at 10:40 PM, James Foster wrote:
I don't see the benefit of the added complexity. As it is now, at compile time the reference is not bound to a global but to an Association holding the global. If you want to change the value of the global you can do so and the method will reference the new value. Also, if you want to do name-lookup at runtime you can explicitly code it to do that.
My objection to always doing run-time name lookup is that I would like to be able to create a module that is self-contained and binds to the the classes I provide without risking that someone else will replace my classes. I would like you to be able to load my module, containing my classes and methods, and we both can be confident that your later changes (including different classes with the same name) will not impact my classes and methods.
If you want a parameterized module, then the module should be explicitly coded to take a parameter and use it explicitly.
yes
Module name: 'FOO' binds: #A to: #Core.Z
Module name: 'FOO2' binds: #A to: #My.Z
My original mail was to measure how much it costs to avoid to have the sharing of the system dictionary class binding in the method literal. Because the design above requires to not share binding.
I'm going over the master of camille and I would like to make such points clearer. So with my little investigation it shows that we can support life programming without sharing bindings.
Once Squeak 4.4 has been released, we'll be re-importing Colin Putney's Environments work, which seeks to do this. It might be worthwhile talking to him about modularisation. (Environments right now only handles class-level issues; it doesn't do anything like selector namespacing or classboxes or anything like that.) frank
Stef
I think it is not as clear to let the module think it is referencing a Point but in fact play a trick on it to have it reference a different class.
- James
On Nov 16, 2012, at 6:17 PM, Stéphane Ducasse wrote:
While I love the idea of sharing the systemDictionary class binding in the method to gain immediate update in case of change I was questioning myself if we could not gain from not having (for example to get parametrized modules).
The point is that we are not constantly changing classes especially when not programming but running program.
So let us do some experiments:
CompiledMethod allInstances size 58891
(CompiledMethod allInstances select: [:each | each classBinding value name = #Point]) size 100
[CompiledMethod allInstances select: [:each | each classBinding value name = #Point]] timeToRun 23
this is the best case since classBinding is at a fixed size
now looking for any reference to Point
(CompiledMethod allInstances select: [:cm | cm literals anySatisfy: [:each | each class = Association and: [each key = #Point ]]]) size 134 methods.
[CompiledMethod allInstances select: [:cm | cm literals anySatisfy: [:each | each class = Association and: [each key = #Point ]]]] timeToRun 91 ms
so it looks to me that this sharing is not something that we should not changed if needed.
What do you think?
Stef