On 18 November 2012 21:53, Stéphane Ducasse <[email protected]> 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 >>> >> >> > >
