James
sorry but I'm at home stopped for 10 days because of a burnout (linked partly
to pharo and the business I want to spawn for the community).
We talked endlessly about namespaces and so far we lived happily without. Right
now I will not talk about that. Read subsystem the paper of wirfs-brock
if you want to see what I would prefer to have. But we need to have a
scientific approach to evaluate.
And yes I read the implementation two years ago.
Finally did you see the list of topics that I mention?
- do you want to help in any of them to make pharo better?
because we have to get them first and I need all my energy for them.
Stef
On Jun 27, 2012, at 12:25 AM, James Foster wrote:
> On Jun 26, 2012, at 12:51 PM, Stéphane Ducasse wrote:
>
>> 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 still don't understand the definition. What do you mean by "another class
> Foo in a class." How can a class be in a class? Is Foo defined in two
> packages? Is the method on the class Foo? Should the name be resolved to the
> Foo in the package containing the method or to another Foo? Perhaps it would
> help if you named the sample classes, packages, and methods.
>
> Are you saying that if the namespace is allowed to be defined (or refined) at
> any level other than the package, then it is lumped into the bucket called
> "class level namespace import"?
>
>>> 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:
>
> Is it your impression that Germán's implementation requires this? If so, on
> what do you base that understanding? Have you looked at the code?
>
>>>> 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.
>
> I still don't know what you mean by "class level import" or why you think
> Germán's implementation fits your definition.
>
>>> 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.
>
> By "Usually" do you mean in pre-namespace Pharo? That is, the class is one of
> the factors that the compiler considers in doing name lookup? Is the "usual"
> approach good? Would it still be a factor considered by the compiler in an
> environment namespace regime?
>
>>> 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.
>
> Do you consider packages to be part of the language? I have always thought
> that one of the nice things about Smalltalk is how little of the development
> environment is actually part of the language. Being able to augment things
> through tools rather than changing the language seems to me to be a feature,
> not a bug.
>
>>> 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.
>
> By "I do not want to know" do you mean "I do not want to be required to
> specify" or do you mean "I do not want anyone else to be able to find out"?
> If I want to know (say, to build tools), would that be okay? If I'm willing
> to let you remain ignorant of a global's source would you be willing to let
> me be enlightened?
>
>> If I want both, at the module import level I write
>>
>> Import: Point from: core as: CorePoint;
>> import: Point from: dev as: DevPoint;
>
> What object implements #'import:from:as:'?
>
>>> 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.
>
> You say that you "do not want to" allow code "to explicitly reference a
> particular namespace." Do you mean that arbitrary code should not be able to
> see a global that is not explicitly imported at package load time and that
> code should never be able to explicitly look at and manipulate namespaces.
> Really? This seems to me to be very much contrary to the existing spirit of
> reflection and introspection in Smalltalk and would make tools much more
> limited. I suspect that this is not really what you mean.
>
> I believe that a package should be allowed to provide a default environment,
> but I don't see the need to make it mandatory or exclusive. I believe that a
> class should be allowed to override the default environment, but I don't
> think it should be required.
>
> If a class is allowed (but not required) to override the default (provided by
> the package/module, for example), does that make it a "class level import"
> (and wrong, in your view)?
>
> What I understand from your statements so far is that Germán's approach
> allows too much flexibility (namespace can be specified not just at the
> package level but also at the class level and explicitly in code). You do not
> want to allow anyone to experiment with different levels of granularity. Is
> that it?
>
> Thanks for engaging in the discussion.
>
> James Foster
>
>
