[Pharo-project] Pharo and Namespaces

Germán Leiva leivagerman at gmail.com
Wed Jun 27 10:16:31 EDT 2012


OT: Late binding rocks!

On Wed, Jun 27, 2012 at 4:46 AM, phil at highoctane.be <phil at highoctane.be>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 <stephane.ducasse at inria.fr>
>
>>
>> On Jun 27, 2012, at 9:24 AM, phil at highoctane.be 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 <stephane.ducasse at inria.fr>
>> > 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:
>> phil at highoctane.be | 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: phil at highoctane.be| Web:
> http://philippeback.eu | Blog: http://philippeback.be
>
> High Octane SPRL
> rue cour Boisacq 101
> 1301 Bierges
> Belgium
>



-- 
Germán Leiva
LeivaGerman at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120627/f8705198/attachment.html>


More information about the Pharo-dev mailing list