Namespaces (was: Re: [ANN]A plan for 3.8/4.0... (insertdrumrollhere))

goran.krampe at bluefish.se goran.krampe at bluefish.se
Mon Apr 5 13:28:45 UTC 2004


Hi all!

"Andreas Raab" <andreas.raab at gmx.de> wrote:
> Chris,
> 
> > Yes Andreas, but for the pessimistic approach to succeed
> > everyone must use something that's "guaranteed" to be
> > unique from each other or you run the risk of returning
> > to the very problem you're trying to solve; name collisions.
> > What name would you choose, then, to guarantee this and also
> > address G&#246;ran's concern about lengthy, wordy,
> > hard-to-read names?
> 
> You guys have all done too much Java lately ;-) One can literally feel how
> confused you are by namespaces and packages. Really, you didn't get my point
> at all. I was *neither* arguing in favour of an optimistic or a pessimistic
> approach - it was Goran who tried to differentiate along those lines.

No, Andreas - I understand what you are saying. But saying that
namespaces have nothing to do with packages is very strange IMHO. It has
*everything* to do with packages. :)

It would be like saying that namespaces have nothing to do with multiple
projects and multiple developers - equally silly statement. Of course it
has.

Sure, I agree that *implementation wise* it should be independent
(though I bet it will mingle in with code dealing with packages
eventually) if we can make it so. But it sure seems strange to talk
about namespaces without considering packages/multiple developers
because those are the primary reasons why IMHO we need them.

> My point was to keep namespace semantics as simple as possible. Namespaces

That is a good point, agreed.

> simply should not do on their own what Goran proposed in the "optimistic"
> approach because this is a task for the tools, NOT for the namespace.

Partly true - I agree that they should not be burdened with
responsibilities they do not need BUT at the same time we need to think
about these things because these issues will come crashing down the hill
as soon as we start using namespaces - don't you agree?

> The
> tools you use can work either way - they may make it simple for you to
> import names which are defined elsewhere (optimistic approach) or they may

That is not at all what I meant with "optimistic".

Eclipse has the alt-shift-o "autoimporter" making it "easy" to import
names but it is still "pessimistic" because the convention that everyone
should create their own little guaranteed unique box for all their
classes removes ALL conflicts.

> require you to explicitly qualify every last crap (pessimistic approach).
>
> But this has NOTHING to do with namespace semantics. The whole semantics of
> a namespace is: It looks for a name and if that name isn't there it answers
> nil. Period. That's all a namespace has to do. *Then* the compiler can raise
> the appropriate exception and *then* the tools can decide what to do about
> it.

Of course - technically I agree with you. But it is an
oversimplification of the subject IMHO.
Technically "Collections are just objects holding onto other objects.".
Sure. And programs are just 1s and 0s. Going down to this level seems
not very interesting.

> > I'm sorry to jump in like this, but I want to voice my support
> > for G&#246;ran's point.  I think he is 100% correct on everything

Hehe, I don't think I have ever seen my name more mangled than that! :)

> > he said about using an optimistic approach.
> 
> To repeat: Whether an approach is optimistic or not is in the tools, not in
> the namespace. If the browser says "okay I'm gonna be optimistic" it can
> silently import the name without ever asking you. If the browser says "na,
> today I'm gonna be pessimistic" it will throw an exception and you'll be
> forced to fully qualify whatever you do. The namespaces are entirely
> unrelated to this.

Well, again it seems you are talking like the "optimistic" approach is
just about "autoimporting", which it is not.

But instead of discussing that again, let me shoot a few simple
questions:

1. What are developers encouraged to do? Do they create their own little
namespace for every project so that when they create their classes in
that project it doesn't matter what they name them? (just like in Java)

2. When a developer types in "Delay" - how will it be looked up by
default? Does each new "project" contain a bunch of default "imports"
(just like in Java) for the basic packages? Or does it look in all
namespaces currently populated in the image and try to find it wherever
it is? Sure - these questions are just "tool issues" but please humor me
with your thoughts. You are the one always saying the UI matters. :)

3. And how is the reference then subsequently "stored", like "Delay" or
like "SqueakBase::Delay"? When compiling the reference today turns into
a class reference in the CM (right?) but how does it look in the source?
Would it always look like "SqueakBase::Delay"? Can we "only" make fully
resolved references?

4. In order to not end up in the same morass as Java is (endless
imports, everyone sitting in their own box by default not getting the
healthy conflicts) - what are you proposing that we should do
differently?

The last question is because from what I have heard so far it sounds
pretty more or less like Java to me. :)

Just to make it clear - I like the Foo::Bar syntax for explicit
references (familiar to most people, readable) and I am not opposed
opening up the possibility of these class names *BUT* I really, really
want to know what comes after that because if we have no plan then I am
betting on this scenario:

As soon as the ENH hits the stream people will start using it *per
package* thus creating (just as in Java) their own little boxes. Notice
how you are saying this has nothing to do with packages - and still I am
betting that there will be a one-to-one mapping to packages.

[SNIP]
> Again (and hopefully the last time :-) whether you have to "stop and
> specify" depends on your tools. Namespaces neither have nor should have any
> requirement in this regard.

It seems to me that your statement is based on the assumption that the
only time a "binding" is "altered" is when the Compiler compiles the
source. Right?

IIRC (just as an example showing that it may work in a different
fashion) a direct reference to something in another "module" in
3.3alpha-modules was actually implemented as a message to that module.
Which means that the lookup was at runtime, not compile time. Again, my
memory may be tripping me.

Now, I am only blabbering to show that I think namespaces *may* be
approached differently. You know that of course - but others may not.

> Cheers,
>   - Andreas

Cheers, Göran



More information about the Squeak-dev mailing list