On Nov 29, 2006, at 2:26 PM, Daniel Vainsencher wrote:

> 1. 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...

> 2. 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).

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?

(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.)

I'd offer a different second goal: the namespace solution should
give clear guidance about what things should be called.

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.
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?

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?

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.

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.

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20061129/67733f11/attachment.htm