Hi!

Highly annoying - I had written a long reply and then it went poof into
bit heaven. Ok, one more go:

[SNIP]
> This is more or less how you'd interact with my tools too, except that
> half
> the steps won't work yet :-).
>
> My thoughts on your proposal, which I'm trying to keep technical rather
> than
> judgemental:
>
> * It's a one-way street to adopt your proposal. I assume that file-outs
> and
> changesets will have all names contain "::". This means that any
> non-namespaced image can't use these file-outs, changesets etc.

It is a tiny changeset (4 modified methods and one added in Parser/Scanner):

   http://swiki.krampe.se/gohu/35

AFAIK that would be enough. Needs testing of course.

> * I assume that operations you perform on your namespaces such as renaming
> them will involve the tools modifying the source code for every method
> that
> uses that namespace? This isn't exactly elegant.

No, you can manipulate bindings too. This would simple change the
reference without touching source or recompiling. Kinda sneaky, but can be
done - I am toying with that now.

And of course if we all move to dynamic lookup (using whatever syntax)
then the problem is easy.
But I think we should allow both static and dynamic references.

> * I also assume that to resolve conflicts of the namespace names
> themselves,
> the tools need to give the namespace a completely new name (which changes
> the source code as it's filed in), and to do this you'd need input from
> the
> user?

Yes, but I have a hard time seeing a solution to this without a registry.
One may argue that the risk of collision would be less in an hierarchical
solution, but I tend to think that it is a small price to pay for the
greater simplicity.

Regarding changing source code - I think it opens up a can of worms
related to SCM and we should not go there.

BUT... (interesting trick coming up, helmet on!) one could argue that
since we are *already* "rendering" references we could be even smarter and
render remapped references differently:

Fruit::Apple (if in fact remapped to NewFruit::) could render as:

NewFruit(Fruit)::Apple

...or something. This is just "thought provocation" from me - not a real
proposal :).

> * If non-namespaced code is loaded into the image, the user will need to
> manually resolve all ambiguous names, of which there will be more of
> because
> developers don't need to use class name prefixes any more.

No, this one is false.

Non namespaced code referencing Apple will resolve to Smalltalk at: #Apple
- nothing else. So it would never "accidentally" collide with Fruit::Apple
because we ALWAYS store the fully qualified name in the source. So
Fruit::Apple is "Smalltalk at: #Fruit::Apple", and Apple is "Smalltalk at:
#Apple" - two different class names simply.

Or perhaps you mean when coding *later*? If you have Fruit::Apple and
Electronics::Apple and Apple in the image - and type "Apple" - yes, it
will ask which one you want. Unless coding in Fruit:: or Electronics::,
then it would autoresolve to the local Apple.

Hmmm, trying to recall if I auto resolve to a "short global" if there IS
such a global (and no local Apple) - but no, I don't think it does. BUT...
this is all just *tool policy* - just set a preference to favor globals -
and it will not ask. :)

Let me repeat that: How your typed characters get resolved is a tool issue
and can/should be controlled with Preferences.

> * Your proposal still involves the use of a global dictionary containing
> all
> global variables and classes. In computer science we learn that the use of
> global variables should be minimised, and your proposal certainly doesn't
> help us in this regard.

I disagree. I think this is just an implementation detail. If you can
improve it by making Namespace instances hold the Assocations instead of
using the trick I am using - then by all means - go ahead! It would be
cleaner implementation wise. But Andreas Raab strongly advised me to not
take on that "world of hurt" and I believed him.

The end result is the same though.

> * Your proposal doesn't completely solve naming collisions but instead
> reduce the likelihood of a collision happening. Collisions can still
> happen,
> and we still need to collaborate among ourselves to make sure two people
> don't use the same namespace.

Ehm, no, I would not put it that way. Two people can *use* the same
namespace - no problem. As long as they actually COLLABORATE and don't
*both* create Fruit::Apple! But this is obvious to me - a namespace can be
shared, they typically are - they just typically aren't shared with the
whole Planet. Sometimes they are only for one developer, sometimes for a
whole bunch.

But I guess you meant make sure two people accidentally don't pick the
same namespace *name*, right? Sure. But again, we are already there -
prefixes EXIST TODAY. We live with it, we have a registry. And if the shit
happens - we make sure there are ways around it. This would be quite rare,
I don't see it as a problem. And it should be sanitized, we don't WANT
multiple namespaces with the same name.

Also... you are saying "collisions can still happen" and YES, I agree. And
there is nothing wrong with that - in fact, I think it is an important
social mechanism! "Oops, you have also coded up something called
SocketStream? Interesting. I bet we should talk and merge or perhaps nuke
one of them etc."

This is GOOD. This is what I have been trying to describe as an
"optimistic approach" - anticipate and embrace collisions and deal with
them when they happen. Instead of letting each developer sit in a sand
castle and create tons of Date classes totally unaware that there are in
fact others out there.

> In effect, what you're presenting as a namespaces implementation for
> Squeak
> is a way to hide class name prefixes from the developer, with a
> well-defined
> prefix format. It doesn't provide code with a particular context to
> resolve
> names in, but rather asks the user on a name-by-name basis to resolve
> ambiguity.

Not entirely true either. It does have some "smarts" when it comes to
resolving - and as I have described, that can be experimented with at
will. Today it already auto resolves local Apples - if there is one.

And the way you say "as a namespace implementation" - you are trying to
make it sound like a trivial, non-worthy solution and not REALLY
Namespaces. Then I humbly ask: What is a REAL Namespace solution? What am
I doing that is NOT REAL?

> I'm not against your proposal, and it doesn't make the situation any worse
> than the current situation except for the filing out issue.

Given what I wrote above regarding filing out - do you still think it is
an issue? And also - does any OTHER solution do it any better? I don't
think so.

> So +0 from me :-). I'd just like to ask you to put an easily-findable
> comment in the core parts of Squeak you change so that it is possible to
> remove it.
>
> Gulik.

If it EVER goes in, of course. And if we (I and Matthew) get DeltaStreams
fully working you can even revert it :). (btw, revert actually already
works)

regards, Göran