Quick comparison of two Namespaces proposals

Jason Johnson jason.johnson.081 at gmail.com
Wed Oct 3 21:21:44 UTC 2007


On 9/18/07, goran at krampe.se <goran at krampe.se> wrote:
>
> This reasoning makes no real sense to me. Why would multiple levels be
> "better"? Are we afraid of running out of namespace names? IMHO the
> proliferation of namespaces and hierarchies of them in other languages
> (like Java) is more based on the fact that they are used for
> organisational purposes.

Well my reasoning is simple:  we have effectively a flat namespace
now, and it doesn't seem to be enough.  If we add just one more level
then we increase our scale by quite a bit but you still have the
siltation like:

Net::Socket
NetFtp::Socket
NetTelnet::Socket

When what you want to say is:

Net::Socket
Net::Ftp::Socket
Net::Telnet::Socket

In other words, with only one level the Namespaces end up having the
same "prepending prefixes" problem as classes have now.



>
> I don't see the need for that many namespaces - in fact, they should
> probably map rather well to *communities* or *projects* rather than
> *packages*. Which again is why I don't consider namespace==package.

But don't communities have sub communities?  And projects sub projects?

> To make myself even clearer: The base Smalltalk-80 libraries could all
> be in one single namespace - and for convenience, let's jus stick to
> good ole "Smalltalk". The whole Seaside community could use ONE
> namespace. The Croqueteers could use ONE or a few. We don't need to
> create a namespace for every little silly class library you know! :)

We don't but we already do after a fasion.  The issue isn't that we
want big complicated Java libraries, the issue is that we want the
simplest name for our class but it's either taken or likely to clash
with something.

> Just maintaining spaces of unique names isn't rocket science IMHO. And
> yes, I agree - my proposal is NOT a *Package* proposal - it *is* a
> Namespace proposal though. Even though calling it "Prefixes improved"
> might make it sound less threatening. :)

Well, the terminology is confusing here.  Your proposal is what C++
calls "namespaces".  In C++ a "namespace" is just a string you prepend
to all classes/functions/variables/etc. that are in that "namespace"
and the compiler has special help so that you don't have to type it
all the time.

In my opinion this was just the simplest way to allow contextualizing
of variables that Bjärne could come up with.  C++'s is mostly complete
but as it is only a compile time convenience there is no possibility
of reflection, etc.

> But why? Smalltalk is different. We can always *learn* from other
> languages but just copying is not good.

> Agreed.  I will make my proposal in a different message.
> I would like to hear the views from the creators in this case. Just the
> fact that they are very seldomly used should IMHO signal us to
> reconsider. They are a namespace imported per class. They do create an
> "environment" where code behaves differently and where you can easily
> "trick" the reader - like having a shared pool shadowing a global etc.

True, in their presence one has to be more careful reading the class
definitions, but when we get a real package system we will have the
same issue.  But honestly the tools can easily point this sort of
thing out for us.

> IMHO a mechanism that widens the gap between what you read and type and
> what is actually executed - is generally a problem. Imports in general
> is such a problem, especially imports per class and in which ordering of
> imports matter (just mention the word "class path" to a java developer
> and watch him/her squirm).

But it can be managed obviously.  Smalltalk gets a big portion of it's
power from the tools, and I think the tools can give us an advantage
here again.

> Also - the fact that a shared pool does not even have to be a global,
> well, it sure makes them "tricksy enough" to warrant some scrutiny IMHO.

Scrutiny is welcome, as it helps us avoid "onions in the varnish", but
I would like to hear Dan or someone make a statement about them at
some point.

> I know that most languages mix these concepts - but that doesn't make it
> mystically right. :) Most code packages (as in deployment unit - think
> class library for example) are developed by individuals or groups of
> developers and it is convenient to create a little "sandbox" in which
> that group can maintain their own names without having to risk
> collisions with the rest of the world. This is what I call "pessimistic
> approach" - as in, you "lock" your own space and that's it. Downsides
> are proliferation of lots of small namespaces "just in case" and
> duplicated classes - lots of Date classes for example (see java again).

But you will see this anyway, we see it now.  Presumably if we had
your solution (or any solution), the prefixes we have now would be
exchanged for a "namespace".  So I know mostly Seaside/Magritte/Pier
and from there it's:   Seaside - WATask, WAComponent, etc., Magritte -
MAComponent, etc., Pier - PRStructure and so on.  Most projects *do*
have what you're calling a namespace already.

I don't think it's "pessimistic", it's just that we want to use the
simplest name we can.  In the examples above, it's not a
"WAComponent", it's a Component in the context of WA or Seaside.

> I am proposing fewer namespaces that are "more shared" and instead
> "embrace collisions" by using an optimistic approach and deal with them
> when they appear.

And how will they be dealt with?  By making a namespace right?  It
seems like you try to argue here like "it's ok, let us have them! you
wont even notice they're there!  They will hardly be used!", but it's
not true.  People want them to use them and the only thing that will
remotely slow them down is the desire for platform compatibility.  And
I don't know how big a factor that is; I see plenty of { } code.

> This is what we do today in SystemDictionary when we
> don't use prefixes - we are in fact maintaining and tending a shared
> namespace (hundreds of developers) and sometimes we end up with
> collisions and then we deal with that. This is GOOD. Putting every
> little silly class in its own little space - like for example if we
> equal class category to namespace - that would be nuts.

Well, I agree that class categories serve a different function, but
you can't believe we will only have one or two namespaces.  You can
look at e.g. the dev image right now to get a feel for how many we
will have.

> I am very curious to why you think so. Even in java the hierarchy is
> just by convention. I definitely do not see any obvious reason to why
> namespaces should have a father-child relation and I definitely don't
> see any obvious interpretation of such a relation. Really, I am not
> trolling. :)

I would never accuse you of trolling.  I don't think of it as
"father/son" as much as "in the context of".  For example, we have the
context of Smalltalk, and currently all our code is within that
context.  Once we have a namespace solution we can expand the contexts
further.  It can be that a namespace or context itself is not unique
in the context of Smalltalk, but something more specific (can't think
of any great examples right now, but a cheesy one might be:  Booking
means something different in the context of Police then it does
TradingSystem).

> This last statement shows clearly that you have not read about my
> proposal in any kind of depth, which of course is fine - it is by all
> means not required bedtime reading. :) But let me just say that imports
> is NOT the only way to get rid of fully qualified names in typing and
> reading.

I don't recall if I have or not, certainly I haven't recently.  But I
realize you don't have to type the names out unless there is a
conflict, but what I'm saying is in 5 years time there *will be*
conflicts if you don't have imports.

> In my proposal all classes (globals of course, but hey - we are talking
> about 99% classes) that have unique short names in the image (that would
> easily be 98% I guess)
> are always rendered and typed in their short
> form. ONLY the classes which are duplicates (Fruit::Orange and
> Color::Orange) would be rendered in fully qualified form and they still
> only need to be typed shortly - the browser will ask which one you mean
> and expand upon save.

Ok, so you don't have to type it.  :)



More information about the Squeak-dev mailing list