A little namespace "proposal"

Colin Putney cputney at wiresong.ca
Tue Apr 13 15:37:52 UTC 2004


Quoting goran.krampe at bluefish.se:

> And you are still only viewing "LookupContext" from Andreas POV namely
> that it has some kind of import list in it. And I have expressly said
> that my proposal for a default LookupContext object implementation meant
> for "normal Squeak" has no such thing.
>
> You can of course say that my proposal sucks and that we surely *must*
> have imports because all the other languages have them. But then say so
> out loud and don't make it sound like my proposal has import lists -
> because it has *none*. Not in namespaces, classes, packages nor in the
> LookupContext. Ok?
> 
> And since it has no import lists then there is no point in storing them
> either. :)

Let's say that your proposal is suboptimal.

The current situation is that there is exactly one context in which names are
resolved. If we introduce namespaces, then there will be several such contexts
in the image. So when we compile code, there must be some way of deciding what
context will be used for lookups, no?

Your proposal is essentially late-bound. The decision is made separately for
each and every lookup. It assumes that most of the time there will not be more
than one context in which a particular name could be resolved, and deals with
such conflicts by asking the user to manually resolve the conflict. It also
dynamically tweaks the display of source code to resolve ambiguities before
it's presented to the user. This is my understanding of your proposal, of
course, so if I've misunderstood, by all means correct me.

I prefer to have more consistency in my coding environment, even at the cost of
some dynamicity. I agree with Andreas that code should be written and viewed in
some specific context, and that temporary excursions into another context
should be explicit. So consider what implied by the presence or absence of a
namespace qualifier in the source code of some method. With your proposal, an
unqualified name means that there is only one class of that name in the image,
but a fully qualified name means there are more than one. With Andreas', an
unqualified name means that the class belongs to the context I'm working in,
while a qualified name is a flag that I'm temporarily reaching out into another
context to do something unusual. That flag was put there by the programmer who
wrote he code, and so conveys information about his intent at the time. Your
proposal only gives me information about the current environment, which is
available though other channels.

> Sounds like you are advocating an "import"-model where packages import
> 1-n namespaces. I still wonder why people are so completely "hung up" on
> import-models. I really do.

Nah, I'm not hung up on imports. They're just make a good way to construct a
lookup context to associate with my code. They're explicit, as opposed to
implicit. If you've got a better way of explicitly specifying a (potentially
complex) lookup context let's hear it.

> I just hope you are aware of the fact that I am coding too. :)

Yeah, but I don't like the direction you're going. ;)

> > Ok, that last bit about assigning a namespace to a package obviously isn't
> > implemented yet, but the rest is. The nice thing about this scheme is that
> the
> > source code doesn't shift under your feet as you load different packages
> with
> > different namespaces, but the neither is it cluttered with fully qualified
> > names.
> 
> Why are you saying "the nice thing about this scheme" as if these two
> things are NOT true in my proposal?
> I repeat again (and again if needed):
> 
> - No source is changing "under your feet" in my proposal. The source (as
> kept in memory, as saved in changelog, as filed out etc) etcALWAYS has
> the qualified names in it. ALWAYS. ALWAYS. Ok?

The source does change. What's in the change log is not what I typed in. What is
filed out is not what I typed. If I load my code into a different image or load
a package into my original image it might not look the same as it did when I
typed it in. If I file in code that some one else wrote I might not see what
they wrote. The code does change, and it does so in unpredictable ways.

> I would appreciate it if people at least tried to understand my proposal
> before bashing it (slightly annoyed). And perhaps even look at the code
> that demonstrates a fully working "rendering" that I describe.

I have tried to understand your proposal, and I have criticized it based on that
understanding. If I misunderstood, by all means correct me. But don't assume
that just because I disagree I must not understand. There *are* other points of
view, you know, and some of them are even legitimate.

For my part, I'm slightly annoyed by the straw man attack in your first
paragraph above. I do not advocate imports because "we surely *must*
have imports because all the other languages have them." To characterize my
position (and that of Andreas) that way is misleading. 

Yes, I do think explicit definition of the lookup context is a good thing. But I
don't insist that it be done through imports, and I certainly don't propose
imports they way other language have done them.

Cheers,

Colin





More information about the Squeak-dev mailing list