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