Hi!
"Jason Johnson" jason.johnson.081@gmail.com wrote:
On 9/17/07, Göran Krampe goran@krampe.se wrote:
- I personally think hierarchical namespaces is "too much". I opted for
single level namespaces and still think that is enough.
But this is a slippery slope. Afterall, flat wasn't enough, why should we think 1 level would be enough forever?
This reasoning makes no real sense to me. Why would multiple levels be "better"? Are we afraid of running out of namespace names? IMHO the proliferation of namespaces and hierarchies of them in other languages (like Java) is more based on the fact that they are used for organisational purposes.
I don't see the need for that many namespaces - in fact, they should probably map rather well to *communities* or *projects* rather than *packages*. Which again is why I don't consider namespace==package.
To make myself even clearer: The base Smalltalk-80 libraries could all be in one single namespace - and for convenience, let's jus stick to good ole "Smalltalk". The whole Seaside community could use ONE namespace. The Croqueteers could use ONE or a few. We don't need to create a namespace for every little silly class library you know! :)
- 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.
Well, the issue I have with your proposal is it isn't really a Namespace/Package proposal, it's simply a proposal to always add your prefixes with a ::, and add some tool support to deal with it.
In my opinion Namespaces are a complicated subject and using such a simple method to deal with them is just sweeping the problem under the rug for someone else.
Well, I disagree of course. :) I think most people think it is so complicated because they mix it up with deployment/packaging AND/OR SCM issues.
Just maintaining spaces of unique names isn't rocket science IMHO. And yes, I agree - my proposal is NOT a *Package* proposal - it *is* a Namespace proposal though. Even though calling it "Prefixes improved" might make it sound less threatening. :)
BUT... please give me use cases etc that you think are not handled by my scheme and I will try to answer with how it would work. Like I just did with Stephane's use case.
I try to make my own solutions as simple as possible, but no simpler. Personally, I think that if we need namespaces now there are good examples to follow: Lisp, Python, possibly Haskell all have good Namespace/Package systems we could emulate.
But why? Smalltalk is different. We can always *learn* from other languages but just copying is not good.
- 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. :)
What is the problem with shared pools? That they're a kind of global variable? I haven't used them much myself, but personally I would prefer a good argument for getting rid of them since the creators of Smalltalk seem to think they were useful.
I would like to hear the views from the creators in this case. Just the fact that they are very seldomly used should IMHO signal us to reconsider. They are a namespace imported per class. They do create an "environment" where code behaves differently and where you can easily "trick" the reader - like having a shared pool shadowing a global etc.
IMHO a mechanism that widens the gap between what you read and type and what is actually executed - is generally a problem. Imports in general is such a problem, especially imports per class and in which ordering of imports matter (just mention the word "class path" to a java developer and watch him/her squirm).
Also - the fact that a shared pool does not even have to be a global, well, it sure makes them "tricksy enough" to warrant some scrutiny IMHO.
- Your Namespaces are linked to a Package scheme, I personally would like
to keep these concepts separate.
From Lisp or Python terms "Namespace" and "Package" are synominous. I think you are talking about Package as in "an MC package", no? That is a package as well, but it's from a different namespace. :) In regards to language I don't think there is much difference between the two except that people tend to call their thing "Namespace" if it's extremely simple (e.g. C++'s solution) and package if it's more complete.
I know that most languages mix these concepts - but that doesn't make it mystically right. :) Most code packages (as in deployment unit - think class library for example) are developed by individuals or groups of developers and it is convenient to create a little "sandbox" in which that group can maintain their own names without having to risk collisions with the rest of the world. This is what I call "pessimistic approach" - as in, you "lock" your own space and that's it. Downsides are proliferation of lots of small namespaces "just in case" and duplicated classes - lots of Date classes for example (see java again).
I am proposing fewer namespaces that are "more shared" and instead "embrace collisions" by using an optimistic approach and deal with them when they appear. This is what we do today in SystemDictionary when we don't use prefixes - we are in fact maintaining and tending a shared namespace (hundreds of developers) and sometimes we end up with collisions and then we deal with that. This is GOOD. Putting every little silly class in its own little space - like for example if we equal class category to namespace - that would be nuts.
- You go hierarchical, I stayed simple and kept it on one level.
I think this is fundamentally a hierarchical issue.
I am very curious to why you think so. Even in java the hierarchy is just by convention. I definitely do not see any obvious reason to why namespaces should have a father-child relation and I definitely don't see any obvious interpretation of such a relation. Really, I am not trolling. :)
- You added an explicit import list per Namespace, I opted to not have
imports at all.
For a complete system imports are required unless you want to be typing the whole path out everytime, which is what we have right now (i.e. no need to add a bunch of stuff to just end up where we are now)
This last statement shows clearly that you have not read about my proposal in any kind of depth, which of course is fine - it is by all means not required bedtime reading. :) But let me just say that imports is NOT the only way to get rid of fully qualified names in typing and reading.
In my proposal all classes (globals of course, but hey - we are talking about 99% classes) that have unique short names in the image (that would easily be 98% I guess) are always rendered and typed in their short form. ONLY the classes which are duplicates (Fruit::Orange and Color::Orange) would be rendered in fully qualified form and they still only need to be typed shortly - the browser will ask which one you mean and expand upon save.
AND... they would still be accepted in short form and rendered in short form if the reference is LOCAL - for example if code in Fruit::Apple references Orange you only type "Orange" and read "Orange" even though Color::Orange exists. But this is only policy - but I felt it was a nice thing to do.
And no, not a single import in sight! :)
regards, Göran