A little namespace "proposal"

Andreas Raab andreas.raab at gmx.de
Wed Apr 7 19:21:16 UTC 2004


Hi Goran,

I think the most important part of my reply is going to be this: When you
write something like "clearly, you want X, Y, or Z" that actually isn't what
I want. Or maybe it is. Or maybe not. Actually, I don't know myself ;-) What
I'm trying to get across here are larger goals I'm working towards and there
will be many little steps until they are reached. Right now "all I clearly
want" is something that's small and understandable enough to be of use to
follow along on some of the goals I have ;-)

So please keep in mind that everything I say (and I tried to get this across
by saying I'm looking at your proposal from the POV of my goals) has to be
taken with a grain of salt to begin with. I have some ideas, and I think
they *might* work - but whether they actually will has to be proven in
practice.

> Ok, I interpret this to mean that you don't think we should allow to
> "render" Kernel::Delay as just "Delay" even though there is just one
> class Delay in the image. But I will read on...

That isn't *quite* right you know ;-) It depends on your subjective point of
view, on the context you are in. For the particular case of Delay I would
claim that indeed, in a regular Squeak system you *should* see Kernel::Delay
ALWAYS as Delay.

However, for example in the context of using Croquet which has its very own
interpretation of what a "Delay" is you may not. Here, e.g., working in a
Croquet context Delay might be something that is provided to you via
Croquet::Kernel::Delay and if you are in the context of a "Croquet project"
then you should see "Delay" as what is provided to you from Croquet and then
you would indeed have to write Squeak::Kernel::Delay to get to it.

This is what I mean by "conflicting concepts" - the whole idea of a Delay
being bound to an I/O device (in this case the real-time clock of your
computer) is completely out of whack with the semantics defined by Croquet.
It's one big no-no to use it unless you know PRECISELY what you are doing.

> Ok, so you are simply saying that short-form is a no-no, unless for
> local names. That will force the use of imports to make the code
> readable. Sigh.

Sigh ;-) This isn't what I am saying at all. I'm saying "it depends" on the
context of your work.

> > So, to me, a namespace isn't about "my little box" as much as it is
about
> > "my larger context". That's important because as you can see from the
above
> > it is absolutely required to "block" names that originate from
"conflicting
> > contexts". Meaning that the mere requirement of "never specify anything
that
> > doesn't need explicit specification" is not good enough for me here - it
> > leads to conflicts in random places and actually makes things worse. I'd
> > rather use prefixes (which I am today) than to introduce that kind of
> > conceptual confusion.
>
> Hmmm, how can it lead to conflicts in random places? Not sure I
> understand that. But perhaps you just meant "confusion".

It can lead to both. Let me give you another example: If you are in Croquet
"time" is a concept which relates to simulation time in a distributed
computation. That is using "Time millisecondClockValue" doesn't make sense
in the way it used to, as the value returned has to relate to the
distributed simulation and NOT to the real-time clock. However, in almost
all other aspects the simulation time is pretty much like real-time - except
that it isn't driven by the local clock of your computer. So using something
like "Time millisecondClockValue" in the sense of the real-time clock would
be a conflict with the semantics of Croquet. It would also be confusing as
things would start to get subtly different, and people might easily be
confused by "well, what time are you talking about???".

> No hierarchies of namespaces - just a flat list, always storing all
> references in the source as fully qualified names, rendering them in
> short-form and accepting short-form only when it can't be misunderstood,
> each class belongs to one namespace, possibly allowing "shyness" to keep
> the tools non-annoying. All in all, very simple IMHO. :)

It is relatively simple, I agree on that.

> Fine. I am trying to see this from your view too.

You might, but from your response I can feel that you're really missing the
larger point ;-)

> > This I really don't like because (to me) it feels like the creation of
> > "little boxes" instead of "large contexts". So the creation of a
namespace
> > should be something I do quite deliberately because I set a new context.
>
> Ok, well - I have been thinking about that. Will we have objects
> representing the namespaces?

Yes. How could it be different in an oop system?

> So ok - we can create Namespace objects but we could let the tools do it
> "automatically" so that the illusion to the developer is the same.
> Agreed? Then of course I assume you want to put those Namespace objects
> into Smalltalk and then have the local bindings in itself so that:
>
> (Smalltalk at: #Kernel) at: #Delay) == Kernel::Delay
>
> Right? Avi wanted us to just keep all entries in Smalltalk - so should
> we do both? I don't know. Thoughts? Sure, implementation details - but
> it makes these things easier to grasp.

Both. It's one of the major advantages of the system that (if you need to)
you are able to reflect about the system in its entirety. I wouldn't want to
see this go away.

> > This I dislike too, but on the grounds of consistency and it is also why
I
> > like imports. The only rule for qualifying names for me is: If I see an
> > unqualified name, it exists in my namespace. Period.
>
> You know - how the references are rendered can be a Preference.
> Seriously. :) So if you want all non-local references to be fully
> qualified you can get it.

But this is not what I am after. What I want is a context for people to work
in. So clearly, all of the names *should* be seen "unqualified" as they are
clear in the context of someone working in a project and only if there's a
need to specifically "leave the context" you should see qualified names.

> > Otherwise I need a
> > qualified name. This approach partly depends on the "large context"
point of
> > view because I agree that otherwise it would lead to endless imports and
> > qualifications which would only be annoying.
>
> Oh, here is obviously an important point that I am missing. What is in
> fact the "large context" POV that prevents the endless
> qualifications/imports? Must have missed something.

Yeah, looks like it. Okay, let me try (this is *really* hard to put in
writing): Basically you have a "space in which you define your objects" and
that space is typically a package or something similar. There are names you
define in this space for stuff you do on your own.

There are other names however, which you *use* and these names come from the
context you are working in. This context should be very broad and cover
large portions of the system - say something like "Morphic", "MVC" etc. A
*set* of those "name spaces" (quoting it here because I want to emphasize
the "space" as in "Space ... the final frontier..." big, wide, open ;-)
anyway a set of those "name spaces" define your working context. So from
your usage POV you make use of a whole lot of names that are defined in this
context.

And, besides using it you can also *contribute* to that context. So, say, I
load a package like "Morphic-Games"; the names which are in there (FreeCell,
Tetris, Chess) would *contribute* to the "names I can use" when using
Morphic.

So maybe it's accurate to say that this is *both* about having "your little
box" in which you can *define* names and "the larger context" from which you
*use* names. And it may be very worthwhile to have a distinction between
"fundamental concept names" (say, Morph, Delay, Collection) which you are
NOT allowed to conflict with and (hm... don't have a good word here...)
maybe "application names" which don't cover fundamental concepts so it's not
that important if you conflict with them (say, SimpleDelayedMenuItemMorph
;-) You might still get a warning about their existence but it isn't
considered a complete no-no.

Did this help clarifying things a little?

> > Also, note that the above fundamentally violates the "avoid conflicting
> > concepts" rule that I mentioned above - it is the precise point of what
I am
> > talking about that using the name "Switch" in the context of a Morphic
> > project should NOT, NOT EVER, resolve automatically to the MVC class
> > Switch - someone who really "means" to use that MVC switch should have
to
> > state that he is "leaving the concept space of Morphic" by writing
> > MVC::Switch.
>
> Hehe, I could turn your own "weapon" against you and say that - hey, its
> a tool thing.

Oh, yes, absolutely. I'm just trying to push you a little into a direction
which makes it easier for me to get my ideas done ;-)

> This is all based on the fact that all references are stored in the
> source *fully qualified*. So what we in fact are arguing about here is
> the "tool support" I think. See end of this post.

It can be seen this way but the reason why I wouldn't want this is mostly
because I am *trying* to keep the concepts in Squeak and Tweak close so that
they can be used interchangeably. This is to a large extent why I'm in this
discussion after all - it would be (well ... almost ;-) simple just to go
ahead and do it but this might introduce some *heavy* conceptual
discrepancies.

> Eh... let me correct my own ramblings here - my original post was a bit
> flaky I think. Let's presume there is only one Delay in the whole
> image, Kernel::Delay.
>
> Then I am proposing that I can type "Delay" or "Kernel::Delay" and in
> *both* cases it will be rendered as just "Delay" when accepted. But in
> the source (only visible in fileouts, in the changes file etc) it will
> always be full qualified as "Kernel::Delay".

Ah, okay thanks. That's *much* better ;-)

> Yes, you are correct that seeing "Delay" in the browser method
> pane can mean two things:
>
> 1. Either there is just one Delay in the system, God knows where. :)
> 2. Or it is a local binding in the namespace of the class.
>
> I find that little possible "confusion" a small price to pay in order to
> get rid of imports. :)

Say, you could really help me by explaining what precisely bothers you so
much about imports. I really don't understand what you find so problematic
about it - if you look at what I wrote above then "contributing names to a
larger concept space" could be fully automatic, so you "just load something"
and get the names. That these names were "imported" is (in my understanding)
a completely neglectable implementation detail.

> > Here again, it depends on whether the namespace represents a conflicting
> > concept or not. If I define a "Switch" in Morphic there is no reason why
the
> > tools should even bother to say anything. There simply is "no Switch in
> > Morphic".
>
> And this is *exactly* what I am talking about - you are arguing for a
> model that is AFAICT exactly like in Java. I want it to *hurt* if the
> developer creates names that already exists in other namespaces - at
> least I want him to know it and have to do something about it.
>
> In short - you are promoting a pessimistic model, and I want an
> optimistic model. You want to prevent all conflicts by making fully
> private boxes - and I want to "embrace conflicts" and deal with them
> when they occur by creating largely transparent boxes.

No, no, no! Please, no! What I am talking about are large, big, name spaces
that contain lots of names and by default you get a slap on your fingers if
you try to name your object like one of the things that exist in it.
HOWEVER, if something exists in an *entirely unrelated* in fact
*conflicting* name space then it just doesn't matter. It's like saying: Just
because there is a Java class FooBarBaz this cannot and SHOULD NOT prevent
me from creating a Squeak class FooBarBaz.

> When you look at code in browsers, and when you accept code into the
> browsers - Squeak should be helpful. And there is no reason why Squeak
> can't behave differently based on Preferences. The end result in the
> code will always be fully qualified names anyway, so how we get there -
> and how the source is rendered in method panes - can be viewed as simply
> *A Tool Issue*. Right?

Yes and no. But I don't want to digress, so I will say "yes" ;-)

> So, Andreas could use a Preference which only render local names in
> short-form, and only accepts those names in short form. He could also
> introduce some global "import list" that is used to allow additional
> short names from certain namespaces etc, like from Morphic, but not from
> MVC.
>
> That would solve the "no Switch in Morphic" issue, wouldn't it?

It may. If however, systems with such a vastly different semantics (what
name can I use where, how should it spelled, what do I have to expect) will
still be able to work together on more than a bytecode basis... I don't
know.

Cheers,
  - Andreas




More information about the Squeak-dev mailing list