A lightweight namespace "proposal"

goran.krampe at bluefish.se goran.krampe at bluefish.se
Fri Apr 23 08:46:57 UTC 2004


Hi all!

Peter van Rooijen <peter at vanrooijen.com> wrote:
> Hi Goran!
> 
> Thanks for your reply, I just read it all, and thanks for the many 
> agreements. I believe there is a real problem to be solved by namespaces 
> and I have good hopes that it is going to happen, thanks in no small 
> part to your work (and I think Andreas provided much of the momentum by 
> advocating an approach that places high value on simplicity).
> 
> I'm only going to give a short response now, and will probably get back 
> to other individual points you made later.
> 
> > Peter van Rooijen <peter at vanrooijen.com> wrote:
> [snip]
> >>I really believe that it can be this simple, and that this is really 
> >>useful, in this simplicity. Not having implemented it, I hope I didn't 
> >>miss something that makes this proposal not work :-).
> > 
> > Eh... I just assumed you had looked at my implementation.
> 
> :-). I've noticed before that you often answer posts while you are 
> reading them.

Yeah. Saves time. :) I don't always do that - but only for long posts
that I do know I intend to reply to.

> > You didn't touch upon the principles of rendering short names (when
> > possible) in the tools and using only qualified names in the actual
> > source.
> 
> Okay. My lightweight namespaces proposal *avoids* that issue entirely (I 
> believe this follows from the proposal, but I did not make this point 
> explicitly). The source is exactly as it is, no different rendering in 
> different circumstances is required or useful. This is another way in 
> which my proposal embraces simplicity. It introduces no need to modify 
> the browsers or the code management system to render source differently.

Well, I assume you mean that this is ok because you want a very large
part of our common classes to be in the "root" space and thus needs no
qualification. But in the longer run I think this will turn into an
issue. I mean - in the long run we will create more and more packages
and they will more and more often reside in their own spaces - and thus
this will cause the the code that uses these classes to turn ever more
"unreadable" due to qualification.

For example - I am guessing you want to keep Morphic in the "root"
space. But what if a new framework is developed? An alternative? Would
that be in a separate space and would perhaps Morphic itself be moved
then into a space of its own? Either way we will end up with a lot of
qualified names in the code, *assuming we don't go the import route*.
And *I* definitely don't want to go there.

> I *did* elide treatment of the issue of how to compile code under the 
> lightweight namespace system. Part of the reason is that I don't even 
> know how code is compiled currently ;-). Perhaps currently the 
> associations (bindings) are compiled into the compiled methods (can 
> someone in the know answer this?).

Yes, true.

> If this is indeed the current mechanism, it requires scanning parts of 
> the system for the need to recompile as class/method/pool definitions 
> are added or modified. A similar approach can be used with lightweight 
> namespaces.

My proposal avoids complication by simply "doing as we do now" - having
a qualified name in the source. When I say "as we do now" then think
about it carefully. Today it can be thought of that we *do* have
qualified names in the source.
 
> Alternatively, one might adopt a slightly more dynamic lookup mechanism 
> with extra indirection, avoiding recompilations at the cost of dynamic 
> lookups. But this is all in essence an implementation detail.

I agree that it is an implementation detail. But an important one. I am
advocating my route (= qualified names in the source just like today +
smart rendering and smart code correction when entering code) simply
because it removes the need for imports. And that is IMHO a BIG WIN.
Note though that I can't say for certain yet if I am "right" because we
need to experiment with this more. But I think I am right. :)

> Cheers,
> 
> Peter

regards, Göran



More information about the Squeak-dev mailing list