Squeak and Namespaces
goran at krampe.se
goran at krampe.se
Sat Dec 2 08:22:22 UTC 2006
"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
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
> 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
> >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
> >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
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.
More information about the Squeak-dev