Quick comparison of two Namespaces proposals

goran at krampe.se goran at krampe.se
Fri Oct 5 11:45:32 UTC 2007


Hi!

(this whole post smells of "you say tomato, I say tomato" - but anyway)

"Jason Johnson" <jason.johnson.081 at gmail.com> wrote:
> On 10/4/07, Göran Krampe <goran at krampe.se> wrote:
> > Hi!
> >
> > I would actually not want that, I would want:
> >
> > Net::Socket
> > Net::FtpSocket
> > Net::TelnetSocket
> 
> Notice the prefixes?

No, those are IMHO not prefixes (again, the example sucks) - those are
different classes with similar names.
A counter example: in the Delta code we have lots of classes called
BlablaChange. That doesn't mean that Blabla is a prefix - it rather
means that the classes are similar - they are all "changes".

Or an even simpler counter example: All subclasses of Morph! Do you
really consider all the words before the Morph-suffix to be "prefixes"?
Should we thus have 360 namespaces all containing one class called
"Morph"? :)
 
> > Ehm, noting of course that the design is bad in the first place - it
> > should not be different subclasses of Sockets at all. But my point is
> > still made - we should not use the word Socket for tons of different
> > things.
> 
> It's an example, but something more real will come up soon enough.

Sure, there are "overloaded" words that we tend to use quite a lot. But
fine, use them, the only thing it leads to is the system will ask which
one you mean and you will have to read them fully qualified - if it is
not a local reference. The price is quite cheap IMHO.

> > > In other words, with only one level the Namespaces end up having the
> > > same "prepending prefixes" problem as classes have now.
> >
> > I don't think so, you can probably come up with an example - but I think
> > it would be quite rare.
> 
> You just showed me one. :)

I don't think so.
 
> > Actually, I think the biggest reason is that we (we being we who are using
> > prefixes) don't want to "pollute" the global space. And yes, we do want to
> > avoid clashes - but not because it would be terrible but because we
> > currently don't have mechanisms to deal with them.
> 
> And we will still need them with a one bucket namespace system for the
> same reason.  "Smalltalk" just becomes something a bit more narrow,
> but otherwise it's the same situation.

We will still need what? I am lost.

> > But my point still stands - we don't *need* a space for every package.
> 
> I didn't say we would for *every package*.
> 
> > I am not sure I caught the "confusing" part.
> 
> Because different systems call the concept different things.  C++ has
> something very simple and they call it a "namespace".  I think
> everyone else calls the concept either "package" or "module".  This
> may lead one to conclude that the terms mean how the given languages
> implement them (e.g. since C++ namespaces are simple and Lisp's
> packages are complex then namespace must mean something simple and
> package something complex).

Are you saying we should call it something else or? I am calling them
Namespaces OR Prefixes improved. I am not calling them modules, packages
etc.
 
> > I am not saying "They will hardly be used!" - you just said that, not me.
> 
> I didn't say you said it, but that it "seems like", in other words,
> this is how it sounds to me.

Not sure what you mean.

> > For the base classes I *do* believe that. Because we are already
> > maintaining that namespace together and it is working just fine. I didn't
> > mean for the whole world of Squeak.
> 
> As you said yourself, we already effectively have namespaces:
> prefixes.  We are not living together in harmony, we're making
> namespaces the only way we can.  This is what I mean, how can you
> think we will have one or 2 when we don't today?  We have lots.

I never said "one or 2". I wrote *base classes*. We don't use prefixes
in there. We are maintaining it cooperatively and it works just fine.

> > This is an interesting statement that tries to argue that in 5 years we
> > will have much more libraries and code and that this will linearly
> > increase the number of conflicts. At first sight this seems logical BUT it
> > totally ignores the fact that you only get a naming conflict INSIDE AN
> > IMAGE.
> >
> > And since the number of libraries and code in a given image is not likely
> > to increase all that much (some yes, but not much) the reasoning fails.
> 
> You misunderstand me.  I'm not saying in 5 years we will have vastly
> more libraries.  Just the ones we do have converted to namespaces.

Lost again. :) How can merely moving to namespaces (adding prefixes
basically) create conflicts?

regards, Göran



More information about the Squeak-dev mailing list