Hi!

(don't have time to respond to all - but I read all)

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

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.

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

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