My namespace proposal described in Yet Another Try

Göran Krampe goran at krampe.se
Wed Sep 19 16:15:06 UTC 2007


Hi!

> How would enhanced prefixes work to load several versions of the same
> classes ?
>
> For Fruit::Orange and Color::Orange, we have the problem that the
> English word is overloaded but the program entities could perfectly be
> named OrangeFruit and OrangeColor.

Sure, if we are AWARE of both we can avoid the clash - but typically we
aren't aware of both and get into trouble trying to load a class library
or whatever into an image in which we already have an Orange.

> Your proposition makes it more
> practical to invent and work with unique names indeed, but if I
> understand correctly, your proposal moves the problem of clashes in
> class names to clashes in prefixes.

Well, the "moves" is a bit harsh - AFAIK most other schemes do in fact
have names on their spaces and yes, you can end up with clashes in
namespace names too. But that is either more unlikely, solvable with
registries OR even better - solvable by remapping, see below.

> For me, name spaces are about differentiating classes that can only
> have the same name, because they actually are the same concept, only
> in a different shape.
>
> E.g., if for some reason I need to load both Seaside 2.6 and 2.8 in a
> single image, I'm still stuck because they will both use Seaside:: or
> WA:: as a prefix. I would need to change the prefix on the fly while
> filing the code in (or loading it from MC) and, symmetrically, to
> rename the client classes to use one prefix or the other.

Yes and no. :) Yes, you would need (or let us say "be able to"!) change
the prefix "while loading" to something else. And no, I don't think you
need to fall back on editing and recompiling referencing methods (if that
is what you meant by "rename the client classes").

I thought about having some kind of "map" that you can use, like:

WA mapTo: #WA26

...so that references to WA:: from that point on (when compiled) actually
are looked up in WA26::.

Or... you can do it like this too:

- Install Seaside 2.6 (into WA::)
- Install/compile all code that should be using 2.6.
- Rename the WA:: namespace:
       WA rename: #WA26.    (I was actually coding up #rename: today)
- Install Seaside 2.8 (into WA:: which now is free)
- Install/compile all code that should be using 2.8.

If I am not too rusty this can be done without recompiling anything
because the existing bindings can be "rebound in place" so to speak when
we rename the WA:: to WA26:: (reusing the same Association instances).

I haven't played around with such "remappings" yet but don't see any big
hurdles in making stuff like this work.

Btw, isn't it nice to be able to talk about WA:: (the syntax makes it
apparent that I mean "the namespace called WA")? Another nice effect of
using ::. Had I written WA. you would instead wonder why I started this
sentence with a lower case letter and you would not have understood I was
trying to refer to a namespace. :)

Anyway, IMHO the explicit prefixes combined with reified Namespace
instances (with some good protocol/code added) should make these things
clearly doable and understandable.

regards, Göran




More information about the Squeak-dev mailing list