Hi!

"J J" <azreal1977 at hotmail.com> wrote:
> >From: "Ramon Leon" <ramon.leon at 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