A little namespace "proposal"

goran.krampe at bluefish.se goran.krampe at bluefish.se
Wed Apr 7 22:51:36 UTC 2004


Hi!

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

Sure, sounds fine.
 
> 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.

Right on. No problem. :)

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

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

Right. This seems fine with my last "mental" picture of what my little
proposal has evolved to.
 
> 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.

I agree.

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

Right, I sortof managed to grasp that later on in my post :).
 
> > > 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???".

Ok. I was merely thinking about "naming resolution conflicts". But sure,
we both see that there can be problems.

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

Well, it didn't feel obvious to me what your POV is. It wasn't until
lately I started grasp what you meant with "context" - see Avi's post
showing a similar late understanding. :)

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

Well. :) I agree. But sometimes even seasoned Squeakers end up with
solutions in which the objects don't really exist. Anyway, not
important.

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

I agree. Btw, Avi had a very nice idea - he said that, hey - perhaps the
"context" you are talking about - the entity that decides how to resolve
names typed in by the user and finding the correct (for the context)
qualified name - *that* is perhaps what we should call the "Namespace".

So Avi said that perhaps it is simply a protocol that various other
objects can implement - typically say the Browser could. When you type
in some code in the standard Browser it could be "consulted" using the
Namespace protocol to resolve the names.

Then I asked - ok, I like that - but what do we then call "Foo" as in
"Foo::Bar"? A proposal was simply "prefix". Well, I haven't really
thought it through yet - but I like the idea of the Namespace protocol.
 
> > > 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.

Well - in my view the "context" (I just renamed it "Namespace" above :)
) can choose what non qualified names are ok, and also - how to render
the qualified names. So I think it is simply "up to the context". Of
course - I have explained quite a lot how I would like it to work in
"standard Squeak". But there is nothing stopping say Omnibrowser or some
other tool taking a different approach I guess.

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

Yes, this sounds fine with the "Namespace" concept that Avi described.
And that you call "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.

Yeah, ok. :) Note how "easy going" I am all of a sudden. :)

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

Yes, indeed.

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

Yeah, I imagine.

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

Well, all models I have seen which have used something called "imports"
are pretty annoying. :)
Though I admit it is mostly C/C++ "includes" and Java imports that I
have seen. Though most other "similar" languages use something like it
too.

The problems are many IMHO. First it implies that I need to import
something before I can use external names unqualified. Adding and
removing imports is just a pain IMHO. You seem to be advocating quite
coarse groups of names to import - but still. You should see how this
looks in Java, yuk.

And if you "automate" that step then it suddenly is not apparent to me
why the step is there in the first place. Is it because you want to be
able to see all imports that you have? That can't be it - because such a
list could be automatically generated for you anyway.

Is it because you want to be able to affect the actual step when the
import is added - perhaps remapping some name which just happens to be
the same in two different imports? I don't think so, you would have told
me (though I may have missed that).

In short - if you think this is "unimportant" because it can all be
"automatic" - then why do you want it? :)

Btw, imports IMHO are typically just so that you don't have to type or
read fully qualified potentially long names. You earlier said that only
names "defined locally" (I think) would be allowed to be in short form -
all others in full form. But that doesn't sound like what you are saying
now. Now you are essentially saying that all names from imported spaces
can also be written in short form? Hmmm.

And finally imports are a base for "pessimistic" name space management.
:) It means that all other names you invent locally that don't conflict
with the ones you imported are ok. So if you didn't import Morphic you
are free to come up with your own "Morph" class. In my proposal
(including my proposed tool support) adding class Foo::Morph would not
go unnoticed by the tools.

Anyway, that was a few of my notes on "imports". Note though that
earlier I was more or less convinced that you wanted to have imports
specified in Foo (as in Foo::Bar). That is at least how it
conventionally is done. In Java it is per class - which is
excrutiatingly painful. Having them per Foo is slightly better and would
map to per package in Java. Still pain in my book.

Now, finally I have understood (I think) what you mean with "context"
and that would move the whole issue over completely to the tool side -
the "Namespace protocol" idea by Avi. So a context is not something
"persistent" typically, well it could be, but it could also just be
"Right now I am writing a Morphic app and thus I am in the Morphic
context" or such.

And then it turns easier for me, because I am envisioning multiple
implementations of the "Namespace protocol" - perhaps you use one for
Tweak or Croquet and there will probably be one for "Standard Squeak".
And if some of those implementations wants to have some "list" of
"imported prefixes", then fine by me. :)

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

This "disagreement" may be a result of my earlier lack of understanding
of your "context".

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

Right. But I think almost all Squeak packages are potentially related -
I mean, they are all intended for "us" as Squeak developers. That is why
I think the "shy" mechanism may be just enough to handle those
situations. I am open for arguments.

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

Right. I know that it wouldn't be nice if we had 20 different tools. :)
 
> > 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.

Eh... do we really need to be *that* different?
 
> Cheers,
>   - Andreas

Btw, I am just hacking up such a "rendering filter" I am describing.
Found some code in Environment that almost does the same thing and also
found a nice place to hook it in. Will post later when I have it
working. Would be nice if someone else hacked the Scanner to accept the
Foo::Bar syntax. :)

Cheers, Göran



More information about the Squeak-dev mailing list