Hi Goran,

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

*Raising an eyebrow* It has? Tell me then, how does a namespace depdend on a
package? What requirements are there that the namespace wouldn't be fully
functional on its own, without a package? I won't argue that packages may
require namespaces to fulfill their task but I really don't see where
namespaces would require packages. And no, this isn't a trick question. I'd
be interested in where you would see this requirement.

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

Well, your primary reasons may not be mine ;-) In fact they aren't and
that's exactly one of the reasons why I would hate to put "extra semantics"
into namespaces.

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

Depends on what you use them *for*. If you use them to isolate package names
then yes, these issues need to be addressed. But this isn't my goal.

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

Hm... then what do you consider "optimistic"? In a system that is fully
extensible (contrary to Java!) there is in my understanding no difference
between "auto-import" and "optimistic" behavior. Isn't that precisely what
we mean by optimistic - the ability to refer to a name, the system provide a
meaning and we living happily ever after?! ;-) If that's what we're after
would it matter if the precise means were implemented via "auto-import" or
(in lack of exact understanding of what you mean by "optimistic") a
compiler-driven lookup through hierarchical namespaces?

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

No, but it's a good way to understand the responsibilities involved, e.g.,
"who should do what".

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

With the implicit assumptions that "simple questions must have simple
answers", eh?! ;-) We shall see...

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

This one I have a simple answer to: I don't know. Because I didn't spend
much time thinking about this issue, I'm not certain about the tradeoffs
involved and it isn't on my list of goals that I want to address with
namespaces. You should ask someone who cares/understands about the
implications of going either way.

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

Well, first of all it should be looked up in the local namespace only. If
it's there, fine, if it isn't an exception gets raised. The tools may react
differently to that exception but the way I would *imagine* them to work is
along the lines of:

They check the environment to see if they know anything about this name.
Let's assume there is only one guy by this name in the environment. You
would be offered to either "auto-correct" that name into its fully qualified
name or to "import" the namespace it comes from (the reasoning here is that
most likely we want to import entire sets of names, say "Morphic", "Sound",
etc. so it should be simple to say "yeah, get me all of them").

When you have multiple objects under the same name... hm... I guess you
should get them sorted by a bit of heuristics (say, how often was each one
"meant" in the existing code base) and essentially have the same choices as
in the above.

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

I don't understand what exactly you mean by "storing" a reference. In source
code, you would see the precise name under which you spelled the object so
it depends on how you got the system to "accept that name" to begin with.

Can we "only" make fully resolved references? My answer would be yes, since
that's precisely the semantics we have today (don't confuse this with
declaring a variable - this is a tools action and you could do the same for
namespaces).

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

First of all, I am proposing NOT to compare everything with Java - it skews
the way you are thinking about the problem. For example, you are exclusively
looking at the negative aspects as in what namespaces "do to you" instead of
what they "do FOR you" what you would expect them to do, how you would
expect them to work. There are some good reasons to look at Java namespaces
(bad examples should always be studied carefully, there is more to learn
from bad than good examples ;-) but we should certainly not limit our
options by (for example) assuming that we cannot change either language,
compiler, or tools (this gets back to your "optimistic" approach on top) and
most of all, we should get an understanding of what we expect namespaces to
be (this was Colins point and it was an excellent one). Methinks that you
really haven't any need that would be addressed by namespaces, so honestly,
why would you bother using them? I do have a need, a very specific and
urgent one, which is precisely the reason why I want to use them.

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

You see, that's the problem when you compare. Listen up man! ;-) The way I
intend to use namespaces is to within a single systems provide "points of
views" which have clear and obvious names. I don't want to use them to
prevent name conflicts (if you think about it this is impossible - even in
your little box you have name conflicts, right?) I don't want them for
"isolating package names". And ultimately, I don't care if "it sounds" like
Java namespaces ;-) I have a specific need to address, and if Java
namespaces would allow me to express what I need I'd use them ;-)

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

See above - perhaps *from* packages *to* namespaces but not the other way
around, I don't think. But here's the other question - if people decide to
use namespaces that way, what is "wrong" with that use? After all it's
within the decision of everyone to decide whether (for example) they use RB,
or Omni, or Star, or any of the other browsers, hm?! So would it be "wrong"
to decide to use namespaces in a particular way?

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

Source code binding, yes. Which means I'm excluding wild hacks like
rewriting method literals directly from that universe ... which I think is
reasonable ;-)

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

I don't remember either. I should say however, that all that's required is
that the binding is present at compile time, e.g., that it is a "known name"
for the system. There is no requirement that a literal association has to be
used for it - it may as well use messages.

Cheers,
  - Andreas