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