On 9/18/07, goran@krampe.se goran@krampe.se wrote:
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.
Well my reasoning is simple: we have effectively a flat namespace now, and it doesn't seem to be enough. If we add just one more level then we increase our scale by quite a bit but you still have the siltation like:
Net::Socket NetFtp::Socket NetTelnet::Socket
When what you want to say is:
Net::Socket Net::Ftp::Socket Net::Telnet::Socket
In other words, with only one level the Namespaces end up having the same "prepending prefixes" problem as classes have now.
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.
But don't communities have sub communities? And projects sub projects?
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! :)
We don't but we already do after a fasion. The issue isn't that we want big complicated Java libraries, the issue is that we want the simplest name for our class but it's either taken or likely to clash with something.
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. :)
Well, the terminology is confusing here. Your proposal is what C++ calls "namespaces". In C++ a "namespace" is just a string you prepend to all classes/functions/variables/etc. that are in that "namespace" and the compiler has special help so that you don't have to type it all the time.
In my opinion this was just the simplest way to allow contextualizing of variables that Bjärne could come up with. C++'s is mostly complete but as it is only a compile time convenience there is no possibility of reflection, etc.
But why? Smalltalk is different. We can always *learn* from other languages but just copying is not good.
Agreed. I will make my proposal in a different message. 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.
True, in their presence one has to be more careful reading the class definitions, but when we get a real package system we will have the same issue. But honestly the tools can easily point this sort of thing out for us.
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).
But it can be managed obviously. Smalltalk gets a big portion of it's power from the tools, and I think the tools can give us an advantage here again.
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.
Scrutiny is welcome, as it helps us avoid "onions in the varnish", but I would like to hear Dan or someone make a statement about them at some point.
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).
But you will see this anyway, we see it now. Presumably if we had your solution (or any solution), the prefixes we have now would be exchanged for a "namespace". So I know mostly Seaside/Magritte/Pier and from there it's: Seaside - WATask, WAComponent, etc., Magritte - MAComponent, etc., Pier - PRStructure and so on. Most projects *do* have what you're calling a namespace already.
I don't think it's "pessimistic", it's just that we want to use the simplest name we can. In the examples above, it's not a "WAComponent", it's a Component in the context of WA or Seaside.
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.
And how will they be dealt with? By making a namespace right? It seems like you try to argue here like "it's ok, let us have them! you wont even notice they're there! They will hardly be used!", but it's not true. People want them to use them and the only thing that will remotely slow them down is the desire for platform compatibility. And I don't know how big a factor that is; I see plenty of { } code.
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.
Well, I agree that class categories serve a different function, but you can't believe we will only have one or two namespaces. You can look at e.g. the dev image right now to get a feel for how many we will have.
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. :)
I would never accuse you of trolling. I don't think of it as "father/son" as much as "in the context of". For example, we have the context of Smalltalk, and currently all our code is within that context. Once we have a namespace solution we can expand the contexts further. It can be that a namespace or context itself is not unique in the context of Smalltalk, but something more specific (can't think of any great examples right now, but a cheesy one might be: Booking means something different in the context of Police then it does TradingSystem).
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.
I don't recall if I have or not, certainly I haven't recently. But I realize you don't have to type the names out unless there is a conflict, but what I'm saying is in 5 years time there *will be* conflicts if you don't have imports.
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.
Ok, so you don't have to type it. :)