Well I have to admit, there seems to be no harm in doing Göran's proposal. It's an incremental step forward that should buy us a LOT of time, probably as much as we'll ever need. Also, like he said, does not preclude migrating to any other namespace solutions in the future.
That alone is enough to win my vote of support.
On 9/20/07, Ramon Leon ramon.leon@allresnet.com wrote:
The only trouble is the problem is still not totally solved; you can still have a conflict.
Magritte and Magma already both very nearly use the same prefix, "MA" and "Ma", respectively. It's hard for me to accept, after all this discussion and effort and say Göran's finally makes it into the base image, that I could very easily collide with Magritte unless at least one of us renames a bunch of stuff.
We use two letter prefixes because we're forced to see them and type them constantly, with Göran's proposal, it'd be much more common to use Magritte:: or Magma:: as the prefix since you wouldn't be typing it, it'd resolve naturally when you just used the short class name. Granted this doesn't help existing packages with short prefixes, but it'd help new code. If it worked well, I'd sure take the time to rename my code to use it.
How many possible two-letter prefixes are there; 26 squared is only 676 namespaces and you know they won't all be used anyway. Not nearly enough for a large community developing a large variety of frameworks and applications with the general-purpose tool.
Doesn't matter, see above.
So I guess we'd could all start using larger prefixes to ensure we could grow to a very large community with Göran's approach. Tell you what, I'm gonna stay slick with my two-letter prefixes but Lukas, please rename all your Magritte classes to use a longer one, ok?
If you don't have to type them when working within the package, I doubt you'd care that much.
Ha ha, seriously, I don't see it necessarily as a problem *for me* as long as the tools were *really good* at hiding and auto-prefixing-on-save. However, I dubious that the entire community would be able (let alone willing) to engage in this sort of "collaborative cooperation" when individual project work beckons. No one should really have to, honestly.
But we already do, the tools just aren't smart enough to allow us to hide it. Göran's proposal just takes current practice, prefixing, and adds tool support to make it a much nicer solution. We'd get a lot more mileage out of prefixing with tool support.
Sorry Göran, I guess I'm starting to waffle right back to my original desired solution of three years ago:
> auto class rename on importing
This could potentially be THE simplest, and most fool-proof solution (other than Craig Latta's NAIAD, perhaps). Make this work and we don't seem to need anything else. And it's a solution that is in the dynamic, malleable spirit of Smalltalk as well.
And such a big change that it isn't likely to be implemented, just talked about endlessly until everyone gives up and the status quo is maintained. The thing that makes his proposal so nice is that it's just a tiny change to make the status quo good enough to let us actually have a working solution while everyone argues endlessly about something fancier.
I see three options that are likely
- Do nothing (most likely)
- Do very little, Göran's approach, formalize and add tool support to
*current prefixing practice* (possible, but unlikely) 3. Do a huge change and add full namespaces and get rid of the big bad global SystemDictionary (when hell freezes over in this community)
So, being annoyed by seeing and typing prefixes constantly, and also being pragmatic and wanting to see a solution get accepted by the community, 2 seems the only viable option. As cool as 3 might be, it just isn't going to happen. Maybe I'm wrong, but that's my impression.
Ramon Leon http://onsmalltalk.com