Hi!
"J J" azreal1977@hotmail.com wrote:
From: "Ramon Leon" ramon.leon@allresnet.com
So conclusion simple namespaces do not help avoid clashes.
Yes they do.
What (I think) he is saying is: Most people are prefixing anyway (I always do), so if you get a clash then you probably tried to make another SPUser. So just putting a couple of colons between SP and User isn't going to save you in that case.
I agree - just like in Java, if I create se.blabla.booboo.Whatchamacallit and you actually create the exact same - then sure, we get a conflict because we used the same namespace - of course!
The conclusion is false - they *do* help avoid clashes, but sure they don't prevent clashes from ever being even theoretically possible. And so? If prefixing didn't actually help avoid clashes - then why do you think people use prefixes in the first place?
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.
It isn't going to hide it from you. It will hide the prefix *so long as no other class in the system has that name*.
Or any other policy is in effect - like for example if the name is defined "locally" etc.
As soon as *one* duplication happens *all* ambiguous classes will be fully prefixed in the source code. In the entire image.
Again, modulo any "special" policies like the local policy yes. You make it sound like we would see *more* prefixes using my solution than with the current custom of prefixing. It is the other way around you know. :)
And we can't do it the way you suggest anyway (well we could but it would be even more complicated) because if the classes are fully qualified every time (they are) and the browser hides all but the actual class every time (it does not)
Not *every time* but theory suggests that they would hide them in 99% of the cases.
then how do we know from looking at someone else's code which actual class they are talking about? Seeing colons is the indicator that there are two or more classes in the image with the same base name.
You lost me. Yes, seeing Foo::Bar indicates that Bar is not unique in your image.
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.
For you it's ugly. I don't notice it at all (so far). So what is also obvious from the traffic on this thread is that some people want it and some people don't. So to me that means it should be a loadable module for those who want it. And it is.
The problem with having a Namespace solution as a loadable module is pretty obvious. Those who use it for their packages will inevitable "force it" upon their users (of their packages).
I just don't think people will use it if is not "standard".
One thing we could think about here is to make some kind of automated tool to switch between the two so that we could all be happy. If you make a package that uses namespaces and I load it from squeakmap my system could automatically turn your namespaces into prefixes and vice versa (ok, this part is hard, but we could just make it manual on package upload).
Well, it is not impossible I guess - but the complexity sounds like it would really diminish the value of this solution. Suddenly it does not sound worth it to me.
regards, Göran