On Jun 26, 2012, at 9:30 PM, James Foster wrote:
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.
Why because it means that in the same package, reading the code containing a class Foo could be a different one. ^^^^^
Class level namespace import means that in a given class, a method accessing the variable Foo may end up pointing to another class Foo in a class in the same package importing another namespace.
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?
No I just say that changing binding of variables at the class level is not a good granularity. I do not want to have Object subclass: #NameOfSubclass instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Bob'
environment:
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.
because this is a class level import.
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.
Usually this is the class of the method.
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.
no this is a question of language design.
In addition, within a particular method it should be possible to explicitly reference a particular namespace environment, whether through syntax (dot or double colons)
No we do not want to have that. We want import to be specified at the border: i.e. during module import. Inside a module the world is flat and as a developer I do not want to know that this Point is from Core when that one is from MyCore. If I want both, at the module import level I write Import: Point from: core as: CorePoint; import: Point from: dev as: DevPoint;
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.
I dislike them both. A module should provide a certain level of encapsulation, else naming convention is good enough. Because else having namespace does not prevent you to have to declare that WA is not a namespace somebody else should use.
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