Namespaces (was Re: Partitioning the image (was Re: Shrinking sucks!))

goran.krampe at bluefish.se goran.krampe at bluefish.se
Mon Feb 14 09:45:34 UTC 2005


Hi Lex!

"Lex Spoon" <lex at cc.gatech.edu> wrote:
> goran.krampe at bluefish.se wrote:
> > So there is no "escaping" going on here. In my code I would write
> > Network::Socket in my code and that would be it. Plain to see. No
> > problem. And if you want to see what namespaces a certain class or
> > namespace uses? Easy - just collect all those references! And if you
> > want to fileout a class and into another system? Easy again, works just
> > fine because the references are *right there*.
> 
> If I am following the discussion correctly, Stephane's argument -- which
> I have a lot of sympathy for -- is that you should never write
> Network::Socket in your code.  You should import "Socket" at a larger
> scope.
> 
> What do you think?  Why is it okay to have all these explicit namespace
> dereferences scattered through your code?

Eh... Lex? I have been arguing my Namespace implementation with you tons
of times IIRC.

My solution let you type "Socket" and it will read "Socket" but in the
actual source it will say "Network::Socket". As long as Socket is unique
in the image (there being no OtherNameSpace::Socket).

And what is so damn "wrong" with "explicit namespace dereferences"? Did
you read my explanation?

> > Having "imports" on the namespace level IMHO creates more headaches than
> > it solves. For example - if I move a class to another namespace (using
> > my namespace model) - no problem, it just works.
> 
> Whoa, you don't want to have them at all?  That is extreme and (to my
> knowledge) novel.

Lex come on... I am SURE you posted in these threads back in 2004,
april. I will not reread your postings then but I am fairly sure you
know all this. Do you really want me to explain it all YET AGAIN? Sure
in short:

Yes, I don't want imports at all. Extreme and novel? Not really. It is
EXACTLY the way stuff works TODAY. There are no imports today. We use
prefixes today and that is VERY, VERY similar to my solution, with the
difference that Squeak KNOWS about them.

>  At the very least, won't this be annoying in a
> thoroughly namespaced world?  Do we have to type Collections::Array to
> get an array?  Morphic::RectangleMorph?

Of course not and frankly I think you are trolling right now. You can't
possibly have just forgotten all that was written/read by you back in
april 2004. But again, patient as I am I can answer you once more:

You will be able to write and read the short form "Socket" iff:
	1. There is only one "Socket" in all namespaces in the image. (the
common case)
	2. There are multiple "Socket", but you have one in the current local
namespace.

This means in practice, for all names that are still unique, you will
only have to write and read the short forms. This covers 99% of the
names I am betting. Also - my proposal makes the above logic a "tool
issue". Different people could elect to have different rules - it
doesn't matter - because the SOURCE will ALWAYS have fully qualified
names.

And again my original proposal is here:

	http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-April/07681
7.html

(I haven't proofread it, but I think it is still valid with my
implementation)

> Imports seem important, and it is worth thinking about how they will
> work.  It is fine to say that you don't answer the imports question, but
> it is a question that needs to be answered eventually as far as I can
> see  (what alternative is there?).  Ideally, the model of namespaces
> themselves should at least *support* a good imports mechanism.

What do you mean "seem important"? What do you mean "I don't answer the
imports question"?

IMHO you haven't made any good case why we need imports. And as usual it
doesn't seem you are even reading my posts or have actually looked at my
proposal.

Now, before you reply to this post just reiterating your questions -
PLEASE read my proposal or look at my WORKING implementation available
on SM.
 
> -Lex

regards, Göran



More information about the Squeak-dev mailing list