Hi!
Long post - probably not that interesting for most people. :)
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
I would actually not want that, I would want:
Net::Socket Net::FtpSocket Net::TelnetSocket
Ehm, noting of course that the design is bad in the first place - it should not be different subclasses of Sockets at all. But my point is still made - we should not use the word Socket for tons of different things.
Also, noting that I am not advocating splitting base classes into spaces either - so there would not be any Net:: at all.
In other words, with only one level the Namespaces end up having the same "prepending prefixes" problem as classes have now.
I don't think so, you can probably come up with an example - but I think it would be quite rare.
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?
They do, but not that often and it would most probably not need to be represented as a "sub space" if they do. For example, Seaside might be considered a "sub community" of the Squeak community - but we sure don't argue that it should be a "sub namespace of Squeak". Same goes for most projects I suspect - Scriptaculous being a sub project of Seaside? Sure, but it doesn't force us to make it a sub namespace.
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.
Actually, I think the biggest reason is that we (we being we who are using prefixes) don't want to "pollute" the global space. And yes, we do want to avoid clashes - but not because it would be terrible but because we currently don't have mechanisms to deal with them.
But my point still stands - we don't *need* a space for every package.
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.
I am not sure I caught the "confusing" part.
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.
Just because tools can help us doesn't mean it is a good thing/idea in the first place. IMHO the shared pools in Squeak is an ugly wart. Thank god we only use them very sparingly.
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.
Sure, but again, that doesn't mean they are good per se.
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.
Me too. :) I will meet Dan at OOPSLA later this month and will ask him.
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.
Yes, but the mechanism is not the same. The tools will never ask you about which "Component" you mean so the conflict of short name will not be apparent and thus the current solution is pessimistic.
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.
Sure, and we can decide to do that. But not *all* the time, sometimes we hopefully end up making the name more descriptive instead. Like I did in your Socket example.
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?
No, either we decide to live with them (hurts just a teeny bit - reading a fully qualified name instead of a short one *iff* both packages are in your image) or we rename one of them.
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.
I am not saying "They will hardly be used!" - you just said that, not me. But yes, you will not notice them much at all. What I am saying is that I don't think we need *as many* namespaces as for example the java community uses - but I am not saying you shouldn't use them.
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.
For the base classes I *do* believe that. Because we are already maintaining that namespace together and it is working just fine. I didn't mean for the whole world of Squeak.
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).
I still don't see the great need nor the semantics of it. But that's fine, we don't need to agree at all. :)
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.
This is an interesting statement that tries to argue that in 5 years we will have much more libraries and code and that this will linearly increase the number of conflicts. At first sight this seems logical BUT it totally ignores the fact that you only get a naming conflict INSIDE AN IMAGE.
And since the number of libraries and code in a given image is not likely to increase all that much (some yes, but not much) the reasoning fails.
An example, let's say Magritte uses Component and so does Seaside. Sure, they are used a lot together in many images and perhaps my proposal would eventually make one of them to rename Component to something more specific. But if a specialised Open GL library used a class Component it would most likely not be loaded at the same time in that many images so it would NOT cause the users to cheer for a rename. See my point?
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. :)
Right. And also - if the references are in the LOCAL space then you don't need to read it NOR even choose one in a menu - it will pick the local one and not ask.
regards, Göran
PS. See my other recent post with a different proposal - just to confuse of course. :) :)