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