a namsepaces discussoin! (Was: Re: Partitioning the image (was
goran.krampe at bluefish.se
goran.krampe at bluefish.se
Mon Feb 14 12:47:18 UTC 2005
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:
> 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
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
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
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.
> > 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.
> 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
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
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.
More information about the Squeak-dev