a namsepaces discussoin! (Was: Re: Partitioning the image (was
bergel at iam.unibe.ch
Mon Feb 14 17:57:59 UTC 2005
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.
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
> 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.
> > > 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
> 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.
> regards, Göran
Alexandre Bergel http://www.iam.unibe.ch/~bergel
More information about the Squeak-dev