Hi!
(don't have time to respond to all - but I read all)
On Nov 29, 2006, at 2:26 PM, Daniel Vainsencher wrote:
- Given 2 independently developed systems, each introducing its
own meaning for a new class name, a developer should be able to make them able to live together in the same image without changing the actual code for either. I think this is the real goal of scalable independent deployment.
Yes, that's a good part of it...
Which my solution btw supports fully. :) The only problem would arise if two developers have picked the same *namespace* name - but that is far more unlikely *and* it can easily be solved by remapping or some such mechanism when loading/filing in.
- If the two systems both introduce similar concepts with the same
name, system should facilitate their merging by the respective maintainers. This goal is meant to facilitate sharing code that is living (and I this is what Markus is talking about).
Exactly. This is what I am after when I blabber about "optimistic" approaches compared to pessimistic. The idea that there is real *value* in seeing class name clashes - even if they are in different namespaces - because it would be much better if they did NOT clash.
Remember - we humans only have one bucket of names in our head. We can't keep track of 5 different "Date" classes.
It may be counterproductive to burden the namespace design with this sort of criterion; how do you assess it? The problems to solve with namespaces are the ones brought about by their absence. Is lack of namespaces the reason why people implement variations on the same idea?
Eh, no... But if you look at typical namespace solutions like for example how it works in Java-land - then they suffer from this effect. Everyone happily sits in their own little "pessimistic" sandbox and invents yet another Date, BigNum, Socket or whatever...
(Not just being glib there; the problem is that if you hold out for a namespace solution that brings peace to the Levant, it will be a long wait. And the system needs namespaces.)
No. This "attribute" is available in my solution. Unless I totally misunderstand what Daniel means.
I'd offer a different second goal: the namespace solution should give clear guidance about what things should be called.
Mmmmm, not sure I understand.
Good namespace systems don't arise from syntax, nor from being backed by clever code-manipulation tools. They also, through a mix of constraint and example, give you a really good idea about what the name of something ought to be.
That's important, because if there isn't an obvious way for development effort x to name its stuff (to some coarse level of precision) then there isn't an obvious guess I would make to find that stuff so I could use it.
Sure.
Policy that constrains the choices when you name a piece of code pays that limitation back in spades by making it easier to find everything. In good systems, resolving namespace conflicts is a local matter, about as deep, interesting, and worth attention as the onerous problem of an inherited instance variable name clash (i.e. rare and boring.)
So if you're going to pick a namespace design, it might be worth talking about what kind of naming policy you're going to use. A question to answer: in a namespace-mature squeak, what will be the fully-qualified name of Object ? SharedQueue? Monticello's Package? Croquet TFrame? Seaside internal utiltities?
Right - this is important. I would call the problem "How do we partition our classes in namespaces?".
And this is interesting. Some people mix the concept of modules with namespaces. A Module IMHO is a "separately deployable/loadable unit". It does NOT equal a Namespace.
A Namespace is a space of names in which a single human (or a group) takes on the responsibility of making sure the names in that space are unique and thus most probably are also "coordinated" in some fashion.
So... would we really need to invent fine granular spaces for the current base classes? IMHO - no. For most of what is in Squeak basic we could just use Kernel::, because that group of classes is maintained by *us*.
Object ? SharedQueue?
Kernel::Object and Kernel::SharedQueue. In almost all cases you would not see "Kernel::" in the code or ever type it because people typically make sure that their own classes don't clash with the classes in Kernel::.
Btw, note how I have started using ZZZ:: to refer to a Namespace. Kinda nice, right? That notation is typically an effect of the fact that they aren't hierarchical.
Monticello's Package?
Monticello::Package. MC is a good example because it typically has quite a bit of classes that could clash with other classes in Kernel. So either we put Monticello in the Kernel - or we use a Namespace of its own.
Croquet TFrame?
Croquet::TFrame
Seaside internal utiltities?
I would almost never have more than one Namespace for a single project. So all Seaside classes should be in Seaside:: just like today (WA*). Why? Because again - we aren't talking about "modules" - we are talking about a space of names. Why would the Seaside developers have problems with name clashes *within their own project*?
And when I come along with my new little pet project, how do I decide what to start calling my own things, and how is my claim laid to those names I use?
Use a descriptive name - typically the name of the project. We do have SqueakMap and we could easily maintain unique public namespace names there.
But we should not depend on that - we just have to have nice functionality to help us if we suddenly happen to get a namespace name clash. But again - that is easy IMHO.
Then once you've thrashed out that side of the namespace question, maybe it will be easier to look at a design, and assess where it moves you in relation to the goal.
Meanwhile, Tim R. asks,
Forgive me if I'm being hopelessly naive here (remember, none of my degrees are in CS ) but isn't namespaces something that has been solved before?
Of course. And I don't think it's a stretch to say that the many modern answers are convergent on most of the basic points.
Which doesn't mean that they fit Smalltalk/Squeak or are good in general.
You get local short names, and fully-qualified long names; you import a long name once to use short names a lot. There's policy that lets you know what long names you're supposed to choose. People adhere to the policy because it guarantees goal 1) by construction... policy-guided fully qualified names are always unique.
Sure, many systems work this way and I urge you to reconsider. There is a REASON for Smalltalk being different and having unique values.
A common trick is to say that you use your domain name as the basis of your names, and leave your use of the tail to your own disgression. Platform components usually have a reserved rooting that is structurally the same as all the rest. That makes it always obvious when you're using 'core' stuff, and what you have to keep track of as a dependency.
There's variance in the status of intermediates (I.e., If I have a namespace Foo.Bar.Baz, is Foo.Bar a scope in which entities live, or is it just a partial name? Can I import 'Foo', or Foo.Bar in one swoop, or is there a 'package' notion that makes the next-to-last level special?)
There are questions about the interaction of namespace scoping rules with others in the language. E.g. does a class in package X which inherits from a class in package Y, automatically have unqualified access to the inherited instance variables of the Y class? (Probably, given Smalltalk's approach to protection, but it is a question to answer.)
And then are minor local questions about syntax and implementation :-).
-brad
My biggest gripes with the systems you describe are:
- Imports generally suck as Java has more or less proven IMHO. See my other post where I describe Eclipse etc.
- Hierarchies generally suck. They make everything much more complex and most people don't understand what the parent-child relation actually *means*. Does it mean that importing xx.yy also imports all its children? Does it mean that yy sees everything in its parent? Or is it just an elaborate boring scheme to make sure namespace names are unique - which people still can break by just using xx?
Remember - in Smalltalk prefixes has more or less "solved" our issues - even though in a very crude way. They are not hierarchical.
Make sure you understand *why* you want imports and hieararchies. I urge you. :) The "feel" of Smalltalk is a fragile thing. I took great care in preserving that feel with my solution. Don't think that just copying a solution from another language will preserve that feel.
regards, Göran