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
>
>
