Hi Andreas!

I thought I should reply to this one first - and then I will later today
actually post a little "proposal" - or at least some "food for thought"
which you can shred to pieces at will. :)

Yesterday on the bus home I formulated a "namespace solution" that at
least I would like, and I will try it out on you guys. :)

"Andreas Raab" <andreas.raab at gmx.de> wrote:
> 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.

Again you are taking the "mathematical stand" and I see no real point in
trying to argue along that line. If you read Dan's post about the issue
you see that he immediately started talking about
installing/uninstalling packages - I find that to be at least some
indication that these things affect each other.

I truly don't think we can adopt a namespace solution without
considering packages - and vice versa. I also note that Stephane wrote
that he thinks the solutions turned rather complex if you don't consider
these things together (or something like that).

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

And for the umpth time - I am not proposing "exra semantics". In the end
it will hopefully turn out separated as you say - and I think so too.
But I still don't think *this discussion* is interesting without taking
the larger picture into account. Hopefully my later post will show more
clearly what I mean. :)
 
> > 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.

Well, as I said - when we introduce them "the issues will come". And I
want us to think *before*.
 
> > 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?! ;-)

That is not what I mean, though I agree I haven't defined my meaning of
the word. :)

The "idea" is to not be afraid of conflicts - but instead "embrace them"
and acknowledge them as a "good thing" because they prevent "reinventing
wheels" and pollution of the global namespace that we still have in our
heads (!). And then handle them as they appear. I think my next post
will make it clearer with actual scenarios etc what I mean.

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

Check next post. :) And *yes* - it heavily involves the tools, I agree
with that. And yes - you will probably be able to say "See! It has
NOTHING to do with the actual namespace code!". And I will still
maintain that it doesn't make it any less important to deal with. ;)

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

I find it slightly too "early" to do that, at least personally. I still
want to see the bigger picture. But noone is "wrong" here, I just want
to think a bit top-down and you want to go bottom-up. :)

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

Well, ok. I think this is a very important question.

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

This is interesting. My proposed model in the next post doesn't have
"imports" at all. And I also tackle the issue with "multiple hits" -
because IMHO it is a crucial situation, again see next post. :) (talk
about teaser, eh?)

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

Ok, since I am not a meta-guru I am fumbling here :).

In my proposal I am tinkering with the idea to "render" the reference in
the source code differently based on how "qualified" it needs to be in
order for the reader to know what is referenced. The reference itself is
always "fully qualified" since it is in fact an object reference to the
class object (I still assume this is right?).

The idea is that it is ok to have it read "Delay" in the source if there
is only one "Delay" in the whole image. It would also be allright to
type just "Delay" in that situation.

And if not - then it is "automagically rendered" as "Kernel::Delay" (or
whichever is correct) so that it always shows enough info. And you would
be prompted to choose which delay you mean when writing only "Delay".

This idea is perhaps not feasible in the current Squeak - I am not sure.
But it would be very neat IMHO. And as you say - we can change the lang,
the tools - whatever we want, right?

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

I think/hope you will give me a bit more credit than this when reading
my proposal.

The reason I am comparing with Java is because it seems to me that what
you are proposing is the *exact same mechanism* as Java has. And IMHO it
sucks. :) To *me* it seems that *you* are limiting your options.

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

Eh... well, that is what I have been saying all along! :)

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

I believe you wrote strongly that we are... well, can't remember the
exact words but it was something about "dying in our own excrements" or
something. So I do think *I* and *we* have a need. I just don't want the
same crappy solution that Java has. :)

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

I am not sure how to react.

I mean - are you arguing for a change/addition in "official Squeak" or
are you just brainstorming something you need for your own projects? If
it is the former - then I think we are entitled to discuss it. If it is
the latter - then fine, you are free to ignore my thoughts.

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

No, of course people can do what the heck they like.

<rant>
Hey, here we go again - listen up people, this Goran guy is trying to
form some sort of convention or agreement in our community regarding
namespaces! Lynch him! We don't need no stinking conventions! And while
we are at it - why don't we tear down that tyrannic SqueakMap too! We
can all have our own little catalog!

And frankly, why even bother with having a standard way of reporting and
fixing bugs! Can't we just all do it the way we like? Sigh...
</rant>

It would be nice if we can just acknowledge that, hey - doing some
things coherently might actually be a good idea. It doesn't *have* to be
some communist plot or anything ruining the precious freedom of
Squeakers. (grrr) :)

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

Ok. My little proposal actually is essentially based on that too.

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

Cheers, Göran