Hi!
Hi Göran, all.
On 9/17/07, Göran Krampe goran@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