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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.