OT: Late binding rocks! On Wed, Jun 27, 2012 at 4:46 AM, [email protected] <[email protected]>wrote:
> Yes, finishing things up is the hardest part. It is also the part that > makes people and great art remembered. > > As I wrote yesterday on Twitter: Execution is everything. Ideas are > nothing. > > I should add: and everything gets better with late binding :-p > > Phil > > 2012/6/27 Stéphane Ducasse <[email protected]> > >> >> On Jun 27, 2012, at 9:24 AM, [email protected] wrote: >> >> > Stephane, >> > >> > Wow, there is a limit to your utter awesomeness... Take care! >> > >> > On this namespace thing... Well, in fact, I found that nice with Java >> but at the end of the day, what matters is the modular bit. And we have >> that with packages and MC. We do no need the namespaces really. Prefixing >> the classes works and scales. Look at any Obj-C app, there are prefixes >> everywhere.... and it works well. >> > >> > No having this additional level makes Pharo much more approachable for >> new people. And in order to get traction, this is important. >> >> yes this is why we have camille (a master student student that is turning >> modules around in presence of class extensions and trying to see what would >> be the best solution) >> now we should finish what we started. >> Finishing is more difficult. >> >> Stef >> >> > >> > Phil >> > >> > >> > >> > 2012/6/27 Stéphane Ducasse <[email protected]> >> > 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 >> > > >> > > >> > >> > >> > >> > >> > >> > -- >> > Philippe Back >> > Dramatic Performance Improvements >> > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: >> [email protected] | Web: http://philippeback.eu | Blog: >> http://philippeback.be >> > >> > High Octane SPRL >> > rue cour Boisacq 101 >> > 1301 Bierges >> > Belgium >> >> >> > > > -- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: [email protected]| > Web: > http://philippeback.eu | Blog: http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium > -- Germán Leiva [email protected]
