Hi!

"Jason Johnson" <jason.johnson.081 at gmail.com> wrote:
> On 9/17/07, Göran Krampe <goran at krampe.se> wrote:
> >
> > - I personally think hierarchical namespaces is "too much". I opted for
> > single level namespaces and still think that is enough.
> 
> But this is a slippery slope.  Afterall, flat wasn't enough, why
> should we think 1 level would be enough forever?

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.

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.

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

> > - Imports are done in your code "per Namespace" which is immensely better
> > than like for example in Java where it is per class (well, per file, but
> > anyway). It is still though the major difference with my proposal in which
> > there are *no* explicit imports at all.
> 
> Well, the issue I have with your proposal is it isn't really a
> Namespace/Package proposal, it's simply a proposal to always add your
> prefixes with a ::, and add some tool support to deal with it.
>
> In my opinion Namespaces are a complicated subject and using such a
> simple method to deal with them is just sweeping the problem under the
> rug for someone else.

Well, I disagree of course. :) I think most people think it is so
complicated because they mix it up with deployment/packaging AND/OR SCM
issues.

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

BUT... please give me use cases etc that you think are not handled by my
scheme and I will try to answer with how it would work. Like I just did
with Stephane's use case.

> I try to make my own solutions as simple as possible, but no simpler.
> Personally, I think that if we need namespaces now there are good
> examples to follow:  Lisp, Python, possibly Haskell all have good
> Namespace/Package systems we could emulate.

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

> > - I agree that shared pools theoretically could be replaced with
> > Namespaces, but then we actually have imports *per class*, which I really
> > don't like. You may argue, "but we already have them!" - yes, I agree, but
> > I don't like them anyway and in my proposal I opted out by simply
> > ignoring/not touching them. :)
> 
> What is the problem with shared pools?  That they're a kind of global
> variable?  I haven't used them much myself, but personally I would
> prefer a good argument for getting rid of them since the creators of
> Smalltalk seem to think they were useful.

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.

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

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.

> > - Your Namespaces are linked to a Package scheme, I personally would like
> > to keep these concepts separate.
> 
> From Lisp or Python terms "Namespace" and "Package" are synominous.  I
> think you are talking about Package as in "an MC package", no?  That
> is a package as well, but it's from a different namespace. :)  In
> regards to language I don't think there is much difference between the
> two except that people tend to call their thing "Namespace" if it's
> extremely simple (e.g. C++'s solution) and package if it's more
> complete.

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

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. 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.
 
> > - You go hierarchical, I stayed simple and kept it on one level.
> 
> I think this is fundamentally a hierarchical issue.

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

> > - You added an explicit import list per Namespace, I opted to not have
> > imports at all.
> 
> For a complete system imports are required unless you want to be
> typing the whole path out everytime, which is what we have right now
> (i.e. no need to add a bunch of stuff to just end up where we are now)

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.

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.

AND... they would still be accepted in short form and rendered in short
form if the reference is LOCAL - for example if code in Fruit::Apple
references Orange you only type "Orange" and read "Orange" even though
Color::Orange exists. But this is only policy - but I felt it was a nice
thing to do.

And no, not a single import in sight! :)

regards, Göran