Quick comparison of two Namespaces proposals

Göran Krampe goran at krampe.se
Thu Oct 4 10:59:09 UTC 2007


Hi!

Long post - probably not that interesting for most people. :)

> 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

I would actually not want that, I would want:

Net::Socket
Net::FtpSocket
Net::TelnetSocket

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.

Also, noting that I am not advocating splitting base classes into spaces
either - so there would not be any Net:: at all.

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

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

They do, but not that often and it would most probably not need to be
represented as a "sub space" if they do. For example, Seaside might be
considered a "sub community" of the Squeak community - but we sure don't
argue that it should be a "sub namespace of Squeak". Same goes for most
projects I suspect - Scriptaculous being a sub project of Seaside? Sure,
but it doesn't force us to make it a sub namespace.

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

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.

But my point still stands - we don't *need* a space for every package.

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

I am not sure I caught the "confusing" part.

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

Just because tools can help us doesn't mean it is a good thing/idea in the
first place. IMHO the shared pools in Squeak is an ugly wart. Thank god we
only use them very sparingly.

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

Sure, but again, that doesn't mean they are good per se.

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

Me too. :) I will meet Dan at OOPSLA later this month and will ask him.

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

Yes, but the mechanism is not the same. The tools will never ask you about
which "Component" you mean so the conflict of short name will not be
apparent and thus the current solution is pessimistic.

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

Sure, and we can decide to do that. But not *all* the time, sometimes we
hopefully end up making the name more descriptive instead. Like I did in
your Socket example.

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

No, either we decide to live with them (hurts just a teeny bit - reading a
fully qualified name instead of a short one *iff* both packages are in
your image) or we rename one of them.

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

I am not saying "They will hardly be used!" - you just said that, not me.
But yes, you will not notice them much at all. What I am saying is that I
don't think we need *as many* namespaces as for example the java community
uses - but I am not saying you shouldn't use them.

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

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.

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

I still don't see the great need nor the semantics of it. But that's fine,
we don't need to agree at all. :)

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

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.

An example, let's say Magritte uses Component and so does Seaside. Sure,
they are used a lot together in many images and perhaps my proposal would
eventually make one of them to rename Component to something more
specific. But if a specialised Open GL library used a class Component it
would most likely not be loaded at the same time in that many images so it
would NOT cause the users to cheer for a rename. See my point?

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

Right. And also - if the references are in the LOCAL space then you don't
need to read it NOR even choose one in a menu - it will pick the local one
and not ask.

regards, Göran

PS. See my other recent post with a different proposal - just to confuse
of course. :) :)




More information about the Squeak-dev mailing list