Hi ramon
The point that andreas raised is valid. My question is what do namespaces really bring us?
They would let me type User instead of SSUser, SPUser, KTUser, FAUser, and if multiple User classes were detected, they'd ask me which one I meant. And if one was in the current package, it could assume I meant that one and not have me think about the prefix.
(Did you ever program in VW? Just give it a try. You will come up really fast with we need more tools support. Ok in VW namespaces are not that cool but they do more.)
No, but I hear they aren't so great.
***Namespaces will not let you load a code that have the same name.*** SD::Foo is the same as SDFoo. No matter how you want to read it. So if your code contains SD::Foo already then you
That's not their intent. Their intent is to automate the prefix stuff so we don't have to do it manually. Yes, SD::Foo would clash with SD::Foo... But it won't clash with WA::Foo, ZW::Foo, or QT::Foo, which is how it helps me.
are screwed . If you use the same namespace than me we will clash. The proof is that in VW you have to ***register*** your namespace on a wiki! yes on a wiki. So we could register prefix.
Unnecessary in Goran's proposal.
So conclusion simple namespaces do not help avoid clashes.
Yes they do.
VW people tried to explain to us that yes in certain occasion doing a private import in a namespace is the right action to do. because you can reuse your code and substitute other components...... Sure may in 1.9 % of the case and this is not the problem solved by the proposal of goran!
So I'm not against a solution to a problem but what is the problem we are talking about here?
Manually prefixing classes to prevent name clashes, and being forced to use those long names when the tools could do it for us, and hide it from us in the browsers.
Having shorter Class names? because this is not about name clashes. Namespaces do not solve that....
Namespaces do solve that. They let me have a Foo class in every project without me having to manually prefix them all. To me... the name is Foo, to the compiler/fileOuts, it's the long names which don't clash (WA::Foo, ZW::Foo, QT::Foo).
Now about traits. This is simple if people (that do not try For pragmas, do you see how important they are? We could have Stef
I'm not complaining about Traits and Pragma's, they're great, I was simply pointing out that those are major changes that have recently been adopted, so why not this minor one that'd be such a great help?
Why does it sucks? Really auto completion works, this is simple. It serves its purpose.
Because I don't like Hungarian style notations, my class name should be about the class responsibility, it should have a prefix by convention just to prevent me from clashing with other similar classes. I want to read and write User, not WAUser or FFUser and Gorans proposal allows that.
But what solution really your solution solves? Really at the end of the day when I program what does it solves? What is the problem?
I'll say it again... "Manually prefixing classes to prevent name clashes, and being forced to use those long names when the tools could do it for us, and hide it from us in the browsers."
This is Smalltalk... We shouldn't be doing anything like this "manually" when the tools could so easily do it for us.
Namespaces as simple as defined by goran will not solve this problem of breaking! Do not dream.
I didn't say solve... I said "so easily". Class extensions make guaranteeing this difficult... But Gorans solution would help, for sure. Perfection is not required to make progress. Gorans solution is progress over what we have currently.
My point is that if we want to improve Squeak there are a lot of places where we can spent times: a good package dependencies mechanism that would help us building robust set of MC packages..... But I do not understand what is the problem that namespaces as designed by goran solve.
Do programmers not scratch their own itches? If this topic comes up over and over, and Goran has a solution that some of us think works... Then obviously there is a problem, because somebody bothered to spend the time to scratch it.
I think you're too concerned about what "can" and "should" be done, rather than what "is" being done. The traffic on this thread alone clearly says this is a big issue, if you don't see what Goran's solution solves, then maybe it's not an issue for "you", but it's certainly an issue for me, and for anyone coming in from another language, it's a huge issue.
I don't really care what "can" and "should" be done, those things don't actually exist, they aren't reality. Reality is working code, and working code, when proposed, should be looked at seriously, not compared to mythical non existing solutions like someones idea of "real" namespaces and then ignored on that basis.
reply simply to this question (I still do not understand why I did not stay silent) what is a the real problem solved by this solution ?
Stef
And again I'll say, it's a tiny fix that automates something that we do manually now anyway, and is a pain in the ass. I don't like prefixing my class names, it's ugly. I pump objects across web services to .Net, where my class names are nice and pretty and simple, because .Net supports namespaces, yet I'm forced to uglify them on the Squeak side because I can't name a class something simple in Squeak and feel even mildly safe about doing so.
I'd have class name clashes with other projects of "mine". It's ridiculous that I can't have three projects, each with it's own User class, without being forced to MANUALLY prefix them, and READ and WRITE those prefixes every time I touch code.
Gorans solution removes this burden, by objectifying the prefix, he can parse it off and hide it from me. When I type a method that isn't found, Squeak asks me which one I really meant; it can and should do the same thing when I type an ambiguous class name like User. It should say hey, did you mean WA::User, ZW::User, or QT::User, and then hide the prefix once compiled. This one simple thing would greatly enhance Squeak in my eyes, and I'd bet, in others eyes as well.
Gorans solution seems simple and elegant without actually changing much, or bringing in the headache that apparently VW namespaces or full blown namespaces really are.
Now, I don't have the expertise of many in this thread, I'm simply giving my admittedly naive opinion. If there are any deep technical problems or consequences to Goran's solution I'm unaware of, I'd certainly be more cautious, but like I said... I can already create and use classes with those names without his solution. His solution appears a simple bug fix to me.
Ramon Leon http://onsmalltalk.com