A little namespace "proposal"

goran.krampe at bluefish.se goran.krampe at bluefish.se
Tue Apr 13 07:37:18 UTC 2004


Hi all!

Colin Putney <cputney at wiresong.ca> wrote:
> Quoting Bert Freudenberg <bert at impara.de>:
> 
> > Am 10.04.2004 um 21:35 schrieb Lex Spoon:
> > > The tools-only approach to namespace imports is actually worse than
> > > this.  While I must set up my C indentation to *edit* other people's
> > > code, we are talking about setting up a LookupContext before I can even
> > > *browse* other people's code.  That seems like a major pain and a big
> > > step backwards over the simplicity of browsing Smalltalk right now.
> > 
> > What if we store the lookup context with the file-out? That way, 
> > another user would see exactly what the author intended.
> > 
> > Whenever we file out something, be it a single method or a package 
> > containing hundreds of classes, we could just store the LookupContext 
> > as a prefix. This would define the "default view" when I later file in 
> > this piece of code.
> 
> This makes a lot of sense to me. 

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

> Really, namespaces should be attached to packages. (I can see Andreas and Goran
> both grimacing here - for different reasons - but just hear me out, ok?) That's
> not to say that each package should have it's *own* namespace, but just *a*
> namespace, a definition of the lookup context in which its code is meant to be
> compiled. Packages would be able to include namespaces, but namespaces would
> know nothing about packages.

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.

> The fact that not all code is part of a package yet isn't really a problem - we
> just create a package called Squeak that contains all the spaghetti we're still
> untangling. Heck, that beast is already on SqueakSource.
> 
> Another thing I've noticed about the Namespace discussion to date is that it
> seems to focus entirely on classes. Remember that name resolution also has to
> take into account class variables, pools and globals. So treating a namespace
> as
> a "flat" list of bindings doesn't quite work. 

That is just to keep the discussion somewhat focused. What we really are
talking about are Globals in general.
(Also - I am thinking of perhaps encompassing pool dicts in the same
way, but that is another story. Pool dicts are in fact exactly like
"import list per class" today.)

And I really don't know why a "flat" model wouldn't work. What I mean
with "flat" is that the namespaces holding the globals are not related
to each other - no inheritance nor linking etc.

> Just for kicks I went ahead and implemented a Namespace class along the lines I
> mentioned in my last post. Unfortunately I can't post the code until Thursday
> or Friday, when I'm supposed to get an internet connection installed. However,
> below are some snippets to illustrate how namespaces could be used:

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

> "Ask a class for its namespace, then resolve variable names,
> more or less the way the compiler would do."
> ns := aClass namespace.
> associationOne := ns bindingOf: #Delay.
> associationTwo := ns bindingOf: #Tweak::Delay.
> 
> "Build a custom namespace"
> outer := Dictionary new.
> outer
>     at: #One put: 1;
>     at: #Two put: 2;
>     at: #Three put: 3.
> inner := Dictionary new.
> inner
>     at: #Two put: 'two';
>     at: #Four put: 44.
> ns 
>     addScope: outer;
>     addScope: inner.
> 
> "Do some lookups with it."
> (ns bindingOf: #One) value     "answers 1"
> (ns bindingOf: #Two) value     "answers 'two'"
> 
> "Make the namespace available for reference 
> via fully qualified variable names."
> ns exportAs: #Foo.
> Foo::Two              "resolves to 'two'"
> 
> "Build a namespace for doing advanced graphics, assuming
> that the requisite exports have already been done."
> ns := Namespace new.
> ns 
>     import: #Kernel;
>     import: #Collections;
>     import: #Croquet;
>     import: #Tweak.
> (Package named: 'MyVirtualWorld') namespace: ns.
> 
> 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?

- There is no "clutter" of qualified names since the source is
"rendered" as "qualified enough". And given that 99% of the classes in a
given image are named uniquely they render JUST LIKE TODAY.

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.

> Finally, its simple to implement, simple to understand, and flexible
> enough to handle the really bizarre cases that tools like Monticello,
> SqueakSource and SqueakMap are likely to encounter. 
> 
> I'll post the prototype as soon as I can.
>
> Colin

regards, Göran



More information about the Squeak-dev mailing list