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
|