Great. And what is the conclusion? :) Doru
On Mon, Sep 24, 2012 at 5:57 PM, James Foster <[email protected]> wrote: > Stef, > > Thanks for taking time at ESUG to listen and learn more about our namespace > proposal. I believe that we have cleared up some of the misconceptions > surrounding this complex topic. > > James > > On Jun 27, 2012, at 8:27 AM, Stéphane Ducasse wrote: > >> >> On Jun 27, 2012, at 4:44 PM, James Foster wrote: >> >>> Stef, >>> >>> I'm sorry to hear about your burnout and I understand that you are not >>> prepared to seriously discuss the issues that others have raised. I hope >>> when the issue is raised again (it does seem to come up every year or so!) >>> we can correct some of the misunderstandings that exist. >> >> yes we are discussing regularly that topic and Camille is writing a master >> where all the points are discussed and summarized with pros and cons. >> Now for 20 we should finish all the open tracks we have. >> >> Stef >> >>> >>> Best wishes, >>> >>> James >>> >>> On Jun 27, 2012, at 12:08 AM, Stéphane Ducasse wrote: >>> >>>> 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 >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> > > -- www.tudorgirba.com "Every thing has its own flow"
