Hi!
From: Göran Krampe goran@krampe.se In some sense yes. :) But I tried getting the subtle differences across - like that the name of MCDictionary is not its short name with my solution being in - it is the fully qualified name.
So there is AFAICT no difference from the current state - when we have MCDictionary.
Yes, but here is the difference I see: Right now we have MCDictionary (ok we probably don't, but as an example) and Dictionary. When I see MCDictionary, no problem, I know its for MC. And when I see Dictionary I know it's a pure dictionary. But with your solution, yes it stays like now *for the moment*. But you made this to get used. Which means the MC people will want to change MCDictionary to MC::Dictionary. What happens then? MC::Dictionary gets only slightly (to my eyes) uglier, but now all my uses of Dictionary become Kernel::Dictionary. Right? That's what I don't want.
As I posted a minute ago - no, it would stay Dictionary.
I agree. And yes, there is a cost. But people seem to think that we have these choices:
- Adding my solution now that gives us Namespaces that don't seem so
impressive to all the language scientists (hey, no imports? It must suck).
I'm with you on the complexity of imports. I know it can really suck in other languages. And in smalltalk I think it would be one of the rare things that is *more* problematic then for other languages because you are looking at a method at a time. You would have to put the import statements somewhere else (I think Andreas suggested with the package) and then simply remember them since you can't see it anymore. Or keep two browsers open for every class you edit.
Exactly. And there are other issues - like for example the fact that writing a snippet in a Workspace (or any other text area) suddenly needs to know what imports it is supposed to use...
So it is a complicated problem end to end. Of everything I have heard I think the Gemstone (I think it was) solution was the best over all. It still has the problems with extra burden for programmer memory but you get a lot with it at least.
- Live on with "manual" namespaces using prefixes that doesn't enable
any proper tool support. We have them ALREADY - don't deny it.
Who denies it? I think the disconnect here is simply: you see this as a huge, almost show-stopper level problem. I personally see it as a minor annoyance that actually gets amazingly close while still looking nice and being explicit/obvious (i.e. less burden for the reader, and we all know code is read much more then written). I personally don't want the look of (to me) a beautiful language to change for pain I just don't feel.
It sounds like the "look" will be changed dramatically. We are only stuffing in '::' between the prefix and the rest. It is not a HUGE difference you know. :)
- Wait forever for "stronger cool advanced" solutions that will be
presented, shot down and never enter the official Squeak. And during this perpetual wait we will still be using crappy prefixes, while arguing to death on squeak-dev about different models more incomprehensive than the next.
If the solution is right it will have a good chance to get adopted I would think.
Hehe, the problem with that line of thought is that "is right" is subjective. The more complex solution the likelier it will piss off tons of Squeakers that will stop it dead on squeak-dev.
Traits was a pretty big change, but it fixed a real problem with some huge pain.
Really? A huge pain? I agree that Traits are great etc, but I would not say that we had "huge pain" before we got them.
And also, it hasn't changed how most of Squeak looks afaik.
That is just because they aren't used yet. :)
regards, Göran