Quick comparison of two Namespaces proposals

Göran Krampe goran at krampe.se
Tue Sep 18 08:00:26 UTC 2007


Hi!

> Hi Göran, all.
>
> On 9/17/07, Göran Krampe <goran at krampe.se> wrote:
>>
>> Hi folks!
>>
>> I just read through Michael van der Gulik's page:
>>
>> http://gulik.pbwiki.com/Namespaces
>>
>> Just stumbled over it btw, and I have only read it once and wrote down
>> some notes compared to my own little "venture" in this area:
>>
>> http://swiki.krampe.se/gohu/32
>>
>> Which I like to call "Prefixes Improved" perhaps. Anyway, here goes and
>> this is mainly addressed to Michael btw.
>>
>> Namespace comments:
>>
>> - I personally think hierarchical namespaces is "too much". I opted for
>> single level namespaces and still think that is enough.
>
> We already have hierarchical categories in Squeak. For example,
> "Kernel-Chronology-Tests". I'm making hierarchical namespaces available,
> but
> you don't have to nest things more than one level deep if you don't like
> that style.

Sure, I understand. I *still* would like to stay with a single level. :)
My proposal also keeps the "good old global" level (SystemDictionary) in
which I would presume most of the standard libraries would still live.

> - I personally don't like the "." notation for namespaces, especially
>> since we already use "." for statement separation. I still think "::" is
>> the best I have seen, although granted - this is a tiny, tiny detail.
>
> Meh. I like the dots; they look tidy. If you can give me a good reason not
> to use them then I'm happy to change.

A *good* reason? Hehe, not really. I don't recall the details in
lexer/parser etc - adding support for $: inside global names was rather
simple - I have no idea if it is just as simple with $.

My reasoning behind :: was that it "stands out" in the syntax - you will
not accidentally mistake it for something else. The "." is IMHO not at all
as clear. For example, what does this code say:

    self add: Kernel.Array new: 4

Is it the same as?:

    self add: Kernel.
    Array new: 4

> - Imports are done in your code "per Namespace" which is immensely better
>> than like for example in Java where it is per class (well, per file, but
>> anyway). It is still though the major difference with my proposal in
>> which
>> there are *no* explicit imports at all.
>>
>> - I agree that shared pools theoretically could be replaced with
>> Namespaces, but then we actually have imports *per class*, which I
>> really
>> don't like. You may argue, "but we already have them!" - yes, I agree,
>> but
>> I don't like them anyway and in my proposal I opted out by simply
>> ignoring/not touching them. :)
>
>
>
> To be honest, I've never really used shared pools, so I don't know much
> about how they're used. In my conversion (categories->namespaces) code, I
> turn a shared pool into a sub-namespace of the class they appear in
> (ooh...
> that could be a bug...). I haven't tested this yet. For the meanwhile I've
> left class pools as they are.
>
>
>> - Your Namespaces are linked to a Package scheme, I personally would
>> like
>> to keep these concepts separate.
>
> (background for people: Package is a subclass of Namespace and forms the
> root of a namespace hierarchy).
>
> Why is this a bad thing? Could you be more specific?

IMHO a package is a "deployment unit" more than anything else. A namespace
on the other hand is a "pool of unique names" that we developers share
with each other one way or the other.

I can see a package both using and defining names in several namespaces.
And I can see several packages defining names in the same namespace. Thus
I don't see the need for making a hard connection between the two
concepts.

BUT... I do of course see many good reasons of finding and reasoning about
dependencies between packages by simply looking at the global names they
define or use. It has always seemed like the obvious "inputs and outputs"
of a package and I bet that we could very easily find 90% of all
dependencies just by looking at these names.

regards, Göran




More information about the Squeak-dev mailing list