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

goran.krampe at bluefish.se goran.krampe at bluefish.se
Thu Feb 10 14:40:33 UTC 2005


Hi Stephane!

Now, this posting turned long - not intentional from the beginning.

=?ISO-8859-1?Q?st=E9phane_ducasse?= <ducasse at iam.unibe.ch> wrote:
> > All? That sounds harsh. :) Has anyone actually tried it? I have
> > presented my Namespaces for a group of Squeak/Smalltalkers here at
> > SweSUG and they all liked it a LOT. So... I wonder.
> 
> Ok let us spend some time because we have so much time to get 
> frustrated.

Eh... you sound ironic. I am asking politely for the reasons of your
dislike, nothing else. You may politely tell me you don't have time -
that is fine by me.

> You can read in the archive the messages I sent when you proposed your 
> namespace.

Ok, having found my first postings and having read all your postings
during april in the various threads discussing namespaces:

	http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-April/threa
d.html

...I still do not find any detailed arguments for what is "wrong" with
my solution. And I would like to hear more than broad statements. But
again, if you aren't prepared to discuss this with me - that is all
fine. You might of course have posted later than april - but I don't
have time to scan the archive more than that.

> We do not like the idea that in a method body you can escape your 
> current namespace
> and access a class in another namespace. We do not want to have 
> internamespace spaghetti code.

The above has IMHO nothing to do with the actual namespace model.
Perhaps that sounds funny - but I mean it. If say SocketStream uses
Socket - then the code in the methods in SocketStream will have to refer
to the class Socket *somehow*. So there is a dependency from
SocketStream to Socket - or in other words - SocketStream is a "client"
of Socket.

Now - it doesn't matter what namespace mucka-mumbo we throw at
SocketStream - the dependency or import or reference or whatever you
like to call it *is still there*. Because otherwise SocketStream will
simply not work. :)

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*.

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.

If you move a class to another namespace you will have to remove (but
only if not some other classes uses names imported from there) and add
imports in both affected namespaces. And sure, it can be automated - of
course - but if you automate handling imports - then there is no point
in having them in the first place IMHO.

Anyway - spaghetti isn't created with a certain namespace model - it is
created by programmers. And the only antidote is refactoring.

> We prefer a model where import is done at namespace level (because this 
> is the job of the namespace) and method body only see names imported as 
> if they would be in the same namespace.

And yet again I haven't seen any real arguments for why. I don't accept
just saying "because this is the job of namespaces". Who says so? A
namespace holds names. The names are unique within that space. Period.
IMHO there is nothing intrinsically that says that "imports" should be
done there nor anywhere else.

And finally - the "sees" part. Care to give me a use case? For example -
is your goal for the compiler to complain if I write "Socket" and I
haven't yet imported Network::?

> I hope this helps but I already said that this is in the archives and 
> we always said it, again and again.

No. I haven't found a careful correct argument on what problems you see
with my solution. I have read numerous references to *your* work but I
have yet to find any good arguments on what you see is wrong with my
solution. I am not even sure you have tested it.

But fine, you have no obligation discussing this with me. Just don't say
that you have given me the *reasons* for your opinion - because you
haven't. You have given your *opinion*, but AFAIK only that. And if you
want to refer me to archives again - please refer to specific postings.

> Stef

regards, Göran



More information about the Squeak-dev mailing list