Stef, we (Goran & you & I & most others) are pretty much agreed that we
are not actually going to tackle namespaces right now.  It will not be
addressed until after the image partitioning/packaging.

I think we're near a (good enough) consensus about how to do the
partitioning/packaging.  But we're obviously nowhere near a consensus on
namespaces.  But once you get a discussion going it's hard to stop. ;)

And Goran is right to some degree that there hasn't been that much
specific, targetted criticism of his namespaces proposal.  I fully
expect a *lot* more discussion about namespaces on this list before we
actually adopt something.  (Otherwise, we are in big trouble... that's
just reality.)  But I agree let's try to postpone most of the discussion
until the partitioning effort has gotten started.

- Doug


On Mon, 14 Feb 2005 19:21:43 +0100, "stéphane ducasse"
<ducasse at iam.unibe.ch> said:
> But we do not need namespaces. Why hell are we confusing and discussing 
> everything at the same time....
> I really do not understand. This is enough to deal with packages. 
> PLEASE do not mix concerns.
> 
> Stef
> 
> 
> 
> 
> On 14 févr. 05, at 18:57, Alexandre Bergel wrote:
> 
> > Hi Goran!
> >
> > Regarding your namespace proposition, I had a look at it several 
> > months ago. I do not know if it has evolved or not. I have a couple of 
> > remarks for the version I looked at:
> >   - the import has to be explicitely stated somewhere, and I feel that 
> > in the method dictionary is not a good idea,
> >   - A class should not have the responsibility of defining 
> > relationship between packages. A class is not a package/module.
> >   - If in my code that I write I have a reference to a class A, I do 
> > not want that that one, when loading my code, see FooBar::A instead. 
> > It is simply not the code I wrote.
> >   - I do not want that a method MyClass>>foo reference Foo::A and 
> > MyClass>>bar refence Bar::A.
> >
> > I do not say that you cannot modularize a big system with it. Of 
> > course you can! Your design choice are similar to what Java offers 
> > somehow. However, I feel that relationship between encapsulating 
> > entities such as Package has to be specified in the package itself.
> >
> > We clearly need a visibility mechanism. The class 
> > Namespace/Environment are one possible implementation of it. By having 
> > a look at some VW applications, it occurs that often a namespace is 
> > defined for the whole application. I feel that having namespaces 
> > orthogonal to packages offer a lot of unnecessary expressiveness. For 
> > instance, having an application composed of 5 packages where classes 
> > are spread over 3 namespaces makes it difficult to understand. I think 
> > we should rather discuss on either having a namespace per application 
> > or per package. As a user of it, I would like to avoid to have to 
> > specify a package and a namespace whenever I define a new class.
> >
> > Cheers,
> > Alexandre
> >
> >
> > On Mon, Feb 14, 2005 at 02:47:18PM +0200, goran.krampe at bluefish.se 
> > wrote:
> >> Hi all!
> >>
> >> Well, this reply responds to all thoughts I have read in this read so
> >> far in regards to my proposed Namespace solution which is available on
> >> SqueakMap in a 95% working form (some things don't work yet).
> >>
> >> Summary: I can't see any real problems brought up yet that isn't 
> >> handled
> >> just fine with my solution.
> >>
> >> Here goes in gory detail:
> >>
> >> Cees wrote:
> >>> The sole reason for namespaces, I think, is that names are rightfully
> >>> overloaded. Personally, I think that a Socket should be a Socket and
> >>> there's no place for a Foo::Socket or a Bar::Socket as in two 
> >>> different
> >>> implementations of a Berkeley-style network socket - if they mean the
> >>> same, name them the same; solve the conflicts rather than work around
> >>> them.
> >>
> >> My proposed solution "supports" the above notion very well, since it 
> >> is
> >> "optimistic" meaning that if there are Foo::Socket and Bar::Socket 
> >> they
> >> will "clash" in the sense that if any Squeaker has both  installed in
> >> the image, the code will read out with qualified names and you will 
> >> have
> >> to type qualified names - unless the code is in Foo or Bar.
> >>
> >> In a pessimistic system, like Java, the names would never "clash" and
> >> noone would notice that there are two Sockets. Which is a bad thing.
> >>
> >> This means that name clashes (like the above) will not go unnoticed -
> >> people are bound to get curious and possibly slightly annoyed and
> >> perhaps one will be renamed or the code will be merged into one 
> >> concept.
> >> Or Foo is an electrical package describing a wall socket - and the 
> >> name
> >> clash is acknowledged as a "correct clash", while possibly it might 
> >> get
> >> renamed to Foo::WallSocket just to make people happy.
> >>
> >> Regarding the orthogonality of namespaces contra class categories and
> >> packages:
> >>
> >> My proposed solution is orthogonal and I really don't think package ==
> >> namespace. But the class categories (if we keep them) should probably
> >> map to namespaces in the sense that all classes in one class category
> >> should probably belong to a single namespace. But possibly several 
> >> class
> >> categories could map to a single namespace.
> >>
> >> If we want to restrict my namespace solution in respect to this - fine
> >> by me.
> >>
> >> Then Doug wrote:
> >>
> >>> After reading this, I'm feeling better about PackageInfo "taking 
> >>> over"
> >>> class categories.  I'm not sure it's worth keeping packages and class
> >>> categories orthogonal.  Class categories just plain aren't that 
> >>> useful
> >>> if you have packages, which end up forming a similar (but not
> >>> identical) categorization.  In other words, I'm wondering if class
> >>> categories are eventually headed for the dumpster.
> >>
> >> Yes.
> >>
> >>>> It sounds,
> >>>> though, like maybe namespaces are *too* orthogonal?  Maybe, say, 
> >>>> each
> >>>> category should correspond to a namespace?
> >>>
> >>> Yeah, that might make sense.
> >>
> >> Well, nah. :) But whatever. The class creation template in my solution
> >> does use the class category as the default namespace though, IIRC.
> >>
> >>> I know there have been raging arguments in the past about whether
> >>> namespaces should be orthogonal to packages, I haven't formed an
> >>> opinion on that.
> >>
> >> My opinion is that a package is an installable entity. That is its 
> >> main
> >> characteristic - the smallest installable unit. It doesn't seem 
> >> obvious
> >> to me that this is the same as a namespace, not at all.
> >>
> >> But we may very well elect to have restrictions on how the two 
> >> concepts
> >> map to each other. Haven't thought hard about that.
> >>
> >>> But I'd say we definitely don't want to have all three orthogonal
> >>> concepts in Squeak -- class categories, packages and namespaces...
> >>> let's have two at most.
> >>
> >> I agree. Currently I would suggest:
> >>
> >> 1. Dumping class categories and have browsers that can either browse
> >> namespaces or packages.
> >> 2. ...Or keeping class categories but with the restriction that a 
> >> class
> >> category belongs to ONE package only, meaning a package can have 1 or
> >> more class categories (like PI today).
> >> 3. Keeping namespaces orthogonal to both class categories (if we keep
> >> them, which of course is a compatibility issue, it may be smart to 
> >> keep
> >> them) and packages.
> >>
> >> Alan Lovejoy's posting had lots of insight and AFAICT my solution
> >> supports all his views:
> >>
> >> 	- Class categories are orthogonal to namespaces in my solution, thus
> >> class categories can be dumped or whatever.
> >> 	- A package is a "separately deployable entity". Period. Has nothing 
> >> to
> >> do with namespaces and my solution also keeps it orthogonal to that.
> >> 	- Dynamic loading (well, can't see why/how such a feature would go
> >> against my solution)
> >> 	- Coordination of global names. My solution gives us a good way to
> >> coordinate names globally.
> >> 	- Classes not specifying a namespace. My solution is perfectly
> >> backwards compatible. The globals are still there. If you create
> >> "MyClass" it will sit in Smalltalk, just like before.
> >>
> >> Yanni wrote:
> >>
> >>> Namespaces are just trying to solve the problem of name
> >>> collisions. Different solutions introduce different pain.
> >>> Prefixes have to be short, and then prefixes collide.
> >>> Namespaces, imports, dotted-names, etc. needs more
> >>> bookkeeping and leads to ambiguous names.
> >>
> >> Exactly. This is the problem Namespaces try to solve. Nothing more.
> >>
> >> My solution does NOT suffer from "short prefixes" - a namespace name 
> >> can
> >> be arbitrarily long, because you almost never need to type it out. If
> >> they per chance would collide (two persons creating the same namespace
> >> name) it will be VERY easy to write code that can rename a namespace 
> >> on
> >> import. This can't easily be done with old prefixes - well, it can be
> >> done - but it is much easier with my solution since the ::-part will
> >> clearly show where the namespace name starts and ends.
> >>
> >> My solution also does NOT suffer from namespace management, imports,
> >> dotted-names etc. Namespaces are created automatically on the fly. 
> >> There
> >> are no imports. You only need to use qualified names when ther are
> >> nameclashes in the image.
> >>
> >> Then Alan Lovejoy wrote:
> >>
> >>> Another issue is "private" versus "public" declarations.  Not all 
> >>> global
> >>> variables declared in a module should be "exported" by the module as
> >>> "public" names.  One way to implement this is to use "private" 
> >>> auxilliary
> >>> namespaces that are not organically bound to any particular module. 
> >>> This
> >>> idea so similar to pool dictionaries that it makes a lot of sense to 
> >>> merge
> >>> the two concepts.
> >>
> >> Personally I don't like private/public restrictions. The author of 
> >> code
> >> being reused can never foresee all possible uses of the code. Simple 
> >> as
> >> that. My solution DOES have a little feature though that I call
> >> "shyness" - but it is not at all core to the solution, I just added it
> >> to see how it works. As I have explained all classes that do not have
> >> clashes in the image in multple namespaces can be typed (and will 
> >> read)
> >> in short form and will be expanded to the full qualified form in the
> >> stored source. Then the source is rendered with short names in all
> >> browsers - so the full name is never seen, unless you fileout for
> >> example.
> >>
> >> If the image has Foo::Socket and Bar::Socket then if you type Socket 
> >> it
> >> will ask which one you mean (putting up a popup menu). And yes, this 
> >> all
> >> works today if you have bothered to try my Namespace implementation,
> >> which so very, very few have done.
> >>
> >> Now - there may be clashes that we for some reasons do not want to
> >> resolve. But one of the Socket classes may mostly be for "private 
> >> use".
> >> Then the entry in the namespace can be told to be "shy". which means 
> >> it
> >> will not be considered when short forms are automatically expanded. So
> >> if Bar::Socket is shy I can still type "Socket" and it will
> >> automatically map to Foo::Socket.
> >>
> >> I can still type Foo::Socket though because it is only "shy" not
> >> "private".
> >>
> >> I would never want to introduce private/public mechanisms in 
> >> Smalltalk,
> >> let Java have their pains - we don't need to "import them" to Squeak
> >> (sorry for the pun).
> >>
> >>> Also required is separating the issue of the namespace in which a 
> >>> class is
> >>> declared from the issue of the set of namespaces whose bindings it 
> >>> imports
> >>> (although it shouldn't be necessary for a class to explicitly import 
> >>> the
> >>> namespace in which it is declared.)
> >>
> >> Eh, not sure what you want to "separate" but again, my solution has no
> >> imports and the namespace it is declared in will automatically be
> >> considered "local" when expanding names. So again - it just works.
> >> Simple as that.
> >>
> >>> Finally, for some of the reasons Yanni mentioned (which I didn't 
> >>> quote,) it
> >>> is important to separate the issue of class, module and namespace 
> >>> identities
> >>> from their names.  A professional module/versioning system should 
> >>> treat
> >>> names as changeable attributive values associated with specific 
> >>> versions of
> >>> a programming construct, not as invariant primary keys identifying 
> >>> the
> >>> construct diachronically for any and all versions.
> >>
> >> This part sounds to me like "overdoing it". My solution is very, very
> >> simple. In fact, it is so simple I don't think you guys (those who 
> >> have
> >> tried it, hands up? Ah, right) get it. But anyway, in this respect my
> >> solution is just like today. A class has a name but no id. Craig Latta
> >> wants ids and perhaps they would improve things - and my solution 
> >> would
> >> of course be fine with that.
> >>
> >>
> >> regards, Göran
> >
> > -- 
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.iam.unibe.ch/~bergel
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> 
>