Quick comparison of two Namespaces proposals

On 10/4/07, Göran Krampe <[hidden email]> wrote:
> Hi!
>
> I would actually not want that, I would want:
>
> Net::Socket
> Net::FtpSocket
> Net::TelnetSocket

Notice the prefixes?

> 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.

> > 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. :)

> 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.

> 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).

> 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.

> 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.

> 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.

Hi!

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

"Jason Johnson" <[hidden email]> wrote:
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.

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.

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

regards, Göran