Hi fellas!

First of all - let me just state this CLEARLY so that noone is mistaken:

I am not pushing namespaces for Squeak at this moment. Yes, I have an
implementation that I like and that hardly anyone has looked at (even
though I took the time implementing it *upon request*) and I was merely
trying to get specific feedback on it in contrast to "we don't like it".
That was ALL. We all agree that there are much more important fish to
try. Ok?

Now, having said that I want to respond here. :) And btw, Alexandre -
sorry if my reply below sounds "confrontational" - it is just a result
of me being frustrated for not getting serious feedback. Ok? :)

Here we go:

Alexandre Bergel <bergel at iam.unibe.ch> wrote:
> Hi Goran!
> 
> Regarding your namespace proposition, I had a look at it several months ago. I do not know if it has evolved or not. I have a couple of remarks for the version I looked at:

No, I haven't touched it in a long while so it should be up to date.

>   - the import has to be explicitely stated somewhere, and I feel that in the method dictionary is not a good idea,

Do not understand what you mean. No, you do NOT have to explicitly state
an "import". Just like you do NOT have to import "MC" today to be able
to use MCRepository, right? There you go. Not sure what you mean with
"in the method dictionary" either.

>   - A class should not have the responsibility of defining relationship between packages. A class is not a package/module.

Really? Says who? This sounds like your *opinion* based on your own
models/proposals. My proposal is different. Now, the above explanation
is not enough to me - you need to explain *why*? Give me use cases.
Whatever. Just do not tell me it is "wrong".

>   - If in my code that I write I have a reference to a class A, I do not want that that one, when loading my code, see FooBar::A instead. It is simply not the code I wrote.

Not sure I understand what you are saying here, it sounds like a
misunderstanding.

If you write "A" it will be expanded to the fully qualified name to the
only A in your system - let's say that is Moo::A. It will say "Moo::A"
in the source code (but it will read "A" if you look in the browser).
Good.

Now, if you file your code out and into another system where there is
also a "FooBar::A" (and Moo::A is also there) then it will still be
bound to Moo::A and it will read fully qualified in the browser too -
because otherwise the reader would not know which A it is bound to.

So it is EXACTLY what you MEANT. It will refer to *Moo::A* at all times.
Because that is what it says in the source. It will only "render" in
short form if there is only Moo::A in the image, and if there is only
FooBar::A in the image then it will probably act the same way as if you
file in code today referring to classes that aren't there.

>   - I do not want that a method MyClass>>foo reference Foo::A and MyClass>>bar refence Bar::A.

Eh, why not? If you *want* to access two different A's from the same
class - why shouldn't you *be able* to?

Btw, this is a very rare case, but it actually reinforces *my* argument
that the use of imports makes this hard - with imports you would need to
"locally rename" one of the A's to something else, yaddayadda, not good
at all. And in my solution it is just easy as cake:

You just type "A" and up comes the popup menu asking "Foo::A or Bar::A?"
and you pick the one you meant. And it will read out fully qualified in
the browser so that it is clear which one is being referred. There is no
problem, or you tell me what it is.

> I do not say that you cannot modularize a big system with it. Of course you can! Your design choice are similar to what Java offers somehow. However, I feel that relationship between encapsulating entities such as Package has to be specified in the package itself.

Similar to Java? NO WAY! How can you even say that? I can agree with one
thing - that there is no Package entity in my solutuon - but that is
probably the only thing similar to java.

- Java has imports per class, I have no imports, big difference.
- Java has pessimistic namespaces (you will not notice that you have
multiple "Socket" in different packages), I have an optimistic approach
(you will *notice* when you have multiple "Socket" in your image, but it
will still work fine)
- Java has a hierarchical naming convention, I have a flat list of
namespaces, they have no relationship to each other.
- Java uses dot-notation, I use ::-notation. Well, sure, just syntax but
whatever - I hate dots.
- Moving a class to another namespace would need changed imports and
changed package declaration in the source file, not so in my solution
since I always have fully qualified names in the source. Just move it.


Similarities:
- In Java you can use qualified names in the code. I can too.
- Local overrides work similarly, meaning a local name overrides a name
in another namespace. And you can still refer to the other name using
the qualified name.
- In Java there is no package entity with imports or whatever, same in
my solution.

Well, there may be more but I can't come up with it now.

> We clearly need a visibility mechanism.

And what supports this notion? We are coping quite well, aren't we? My
namespace solution is in fact just "prefixes done nice" and it solves
our issues (naming clashes, local overrides) while being very, very,
VERY backwards compatible.

So in fact - I am NOT arguing for introducing a complex namespace
solution - I am arguing for the opposite, introducing a very simple
solution that most people will say "Hey, this is just like prefixes, but
better". You are the ones arguing for introducing complex solutions. I
am not.

> The class Namespace/Environment are one possible implementation of it. By having a look at some VW applications,
> it occurs that often a namespace is defined for the whole application. I feel that having namespaces orthogonal to
> packages offer a lot of unnecessary expressiveness. For instance, having an application composed of 5 packages
> where classes are spread over 3 namespaces makes it difficult to understand. I think we should rather discuss on
> either having a namespace per application or per package. As a user of it, I would like to avoid to have to specify
> a package and a namespace whenever I define a new class.

I agree to some extent that two or even three (counting class
categories) different concepts makes it all confusing - but I think the
orthogonality can be kept and still avoid most problems. My solution
does this by:

1. The class creation template suggest the first part of the class
category name (IIRC, and if it doesn't it should) as the namespace for
the class. This equals PI. So by default, just by picking the class
category, you will create classes in the same package, given that we use
PI as it works today, with the namespace of the package. Great. For most
cases that is enough, it will ensure "namespace name = package name" for
almost all code.

2. You never need to THINK about namespaces when writing code. Because
there are no imports! You just type "Socket" and bam, it is there just
like before. In fact, most people will *not even notice*! So if some
package has classes in multiple namespaces or whatever - it never
affects YOU as the user of those classes. This is important.

So all in all, thank you very much Alexandre for having the courtesy to
look at my solution. Now, it would be GREAT to hear your reply to what I
have written above.

And again, this discussion DOES NOT IMPLY that I am pushing namespaces.
I just do NOT want my solution to be bashed without proper arguments
presented. If you can point out some REAL flaws I welcome it. I even
know some flaws myself. :) I just don't want to hear arguments based on
"nah, it is wrong because that is not how we would do it".

> Cheers,
> Alexandre

regards, Göran