[Pharo-project] Pharo and Namespaces

James Foster Smalltalk at JGFoster.net
Tue Jun 26 15:30:39 EDT 2012


On Jun 26, 2012, at 11:19 AM, Stéphane Ducasse wrote:

>>>> What happened to the project from Germán Leiva
>>>> http://www.youtube.com/watch?v=n4I7fSVNX2A
>>> 
>>> we do not want class level namespace because this is the mess
>> 
>> As the sponsor for Germán's project, I have some interest in this topic. Stéphane has said a couple times that it is wrong but has never taken time to explain his objections.
> 
> We do not want to have class name resolution at the granularity of a class.

And are you saying this because you think Germán's implementation does this?

> Why because it means that in the same package reading the code containing a class Foo could be a different one.

I don't understand your example. I don't know what you mean by "package reading the code." Are you describing a package that defines classes Foo and Bar, and a method in a class Bar that references the Foo in the same package? Are you providing this example because you think Germán's implementation does not support this use case?

> I'm saying that since years.

I agree you have been saying that Germán's implementation isn't what you want. I just don't understand what you don't like about it.


Name resolution of all variables (including Globals, of which Classes are a subset) should be part of a method compile. At the time a method is compiled, an 'environment' should be provided to the compiler that indicates how global name resolution should occur. This is a tools issue and it should be possible to specify the default namespace environment for the method, for a method category, for a class, for a class category, for a package, and for the system as a whole. In addition, within a particular method it should be possible to explicitly reference a particular namespace environment, whether through syntax (dot or double colons) or through message sends (e.g., a Dictionary's #'at:' method). I prefer not to add new syntax and favor GemStone's implementation over that of VisualWorks.

If you don't have time to discuss this in depth I would be less frustrated if you would wait to say it is wrong until you have time to explain why.

James Foster





More information about the Pharo-dev mailing list