Quick comparison of two Namespaces proposals

On 9/17/07, Göran Krampe <[hidden email]> 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?

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

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.

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

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

> - You go hierarchical, I stayed simple and kept it on one level.

I think this is fundamentally a hierarchical issue.

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

On 9/18/07, Bert Freudenberg <[hidden email]> wrote:
Well it does. :)  Personally I'm not so sold on '.', I just hate to
see <insert barage of hideous languages>'s :: come to Smalltalk as
well.

I don't think the dot is an option anyway given the obvious reasons
which have already been covered.

What do you think of message syntax for this?  I think it could be
done at compile time as well, since the compiler is determining the
reciever of a message anyway.

Well this is quite an interesting proposal in itself, though I would
say this is above and beyond what we need for namespaces at the moment
(given we currently have none at all).  This seems like something that
may prove itself to be the way to go in the future.  I'm interested to
see how it turns out.

On 9/17/07, Igor Stasenko <[hidden email]> wrote:

Maybe you should look at Gorans proposal first.  In general, :: would
separate the prefix from the class name in such a way that the tools can
hide Kernel:: except when there's ambiguity, or in file outs.  Formalizing
prefixes that we all currently do by convention anyway while keeping the
simplicity of a single global namespace and avoiding the need for imports.
It's actually a nice proposal and :: doesn't look bad at all, since you'll
hardly ever see it.

Ramon Leon

I've looked at the proposal, and you will see it.  Today you wouldn't
because there are no namespaces and thus no conflicts.

I agree we need namespaces, I just think we can do better, both in
looks and in functionality.  It's nothing against Goeran, just as I
told him, I think his Delta's thing is right on the money.  I just
think this is really going to "give us only enough rope...."

On 9/18/07, Ramon Leon <[hidden email]> wrote:

> I've looked at the proposal, and you will see it.  Today you
> wouldn't because there are no namespaces and thus no conflicts.
>
> I agree we need namespaces, I just think we can do better,

That's the thing, not everyone agrees about needing them, which in the past
has made adding them a losing battle.

> both in looks and in functionality.  It's nothing against
> Goeran, just as I told him, I think his Delta's thing is
> right on the money.  I just think this is really going to
> "give us only enough rope...."

Which is at least a step forward, more than you're likely to get with any
other proposal.  Watch what a battle adding "real" namespaces turns into,
and you'll see how good formalizing prefixes looks after a while.

Ramon Leon

Hi!

"Michael van der Gulik" <[hidden email]> wrote:
Let me just note that the second version using :: is NOT ambiguous for
the parser - the one using "." seems to be unless I am missing something
obvious.

> Keep in mind that I only expect people to use this syntax when the import
> list allows ambiguity in the names. Typically, you'd just see:
>
> self add: Array new: 4.
>
> because Kernel has been added to the import list.

Of course, and similarly goes for my proposal - you would very rarely
see or type fully qualifieid names there too. But again - I am trying to
put my finger on a parsing disambiguity here. :)

> What I am a bit concerned about is that I've made the BNF grammar more
> complex or that I've made it stupid. If a dot/period is followed by
> whitespace, it terminates the current statement; else it can validly be par=
> t
> of a word or keyword.
[SNIP of change]
Ok, so one package can define names in several different namespaces?
Ehh... that sounds slightly different than what I read - perhaps I
misunderstood the relationship between a Package and a Namespace in your
solution.

> What do you mean by several packages defining names in the same namespace?
> Are you talking about method overrides? Then like I said before, I can't
> work out how to do this without creating a security issue (I'm planning on
> Packages containing completely untrusted code which can be securely execute=
> d locally).

I am not talking about method overrides, no. I am simply talking about
package P1 defining a class X in N1 and package P2 defining class Y in
N1. Nothing magical. :)

But I think you wrote that Package is actually a subclass of Namespace
so perhaps your mental model of package == namespace is making this
sound *crazy*. :) But I still think these two concepts are orthogonal -
even though often we (developers on planet earth) *decide* that one
should be tightly bound to the other.

I see value in NOT making that tie, for once.

> If you're talking about defining the same class in multiple packages, then

No, I am not. :)

regards, Göran

On 18/09/2007, Jason Johnson <[hidden email]> wrote:
> What about message style sytax?
>
> e.g.
>
> self add: (Kernel Array new: 4)
>

This looks like how GNU Smalltalk handles namespaces. Following up the
references in the gst info files, I found some discussion on the
Squeak wiki which includes some work done by Augustin Mrazik in 1992:

http://wiki.squeak.org/squeak/727

Some other dialects already have Namespaces (vw gst ...)

Any desire to be source-compatible?

Nicolas

Ron Teitelbaum a écrit :

Hi!

stephane ducasse <[hidden email]> wrote:
Ok, so to explain your use case further - before N1 had a B, the foo
method was obviously bound to the B in N2 - because there was no other
B. Then you added another B to N1 and then recompile foo and now there
are two B-choices - the local one in N2 or the imported one in N1,
right?

In my proposal this is not a problem at all, this is what would happen:

First we have a class named N1::A and a class named N2::B. There is no
import (since I don't have that concept at all). When typing in method
N2::B>>foo and typing "B" nothing strange or odd will happen - as long
as there is no other B around in the image (in any other namespace)
Squeak will resolve it to N2::B and the *source* stored in method foo
will be:

   ^ N2::B

...BUT it will *look* like "^ B" in the browsers because the short form
is enough - there is no other B around so we render and accept the short
form "B".

Now someone creates another B in the image - N1::B. After that we browse
foo and it still renders in short form. How is that? Well, if the
reference would have been to a class in ANOTHER namespace (non local)
then it suddenly would render like "^ N2::B" because the short form is
no longer "enough". So there is a policy to accept and render short
forms even if there are multiple Bs *if* the reference is LOCAL - which
is the case here.

Anyway, so what if we recompile then? No problem, it is in fact NOTHING
different from now. The reference was always FULLY QUALIFIED in the
source and thus a recompile is no problem at all.

regards, Göran

Hi!

"Jason Johnson" <[hidden email]> wrote:
> On 9/17/07, Göran Krampe <[hidden email]> 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! :)

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

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

Array is a class, not a message. This is /not/ elegant and simply doesn't make sense. This is my last comment on this approach.

What is possible is:

self add: (Kernel-Array new: 4).

Here, #- is a message.

Michael.

This is a problem that I'm currently working with. I think I'll try completely disallowing ambiguous names. If a name in a method can resolve to anything other than exactly one binding, then the compiler complains. The user will have to resolve this either by reorganising the local import list, or making the name less ambiguous using either dotted notation or Krampe notation ('::').

Michael.

On 19/09/2007, Michael van der Gulik <[hidden email]> wrote:
> Array is a class, not a message. This is /not/ elegant and simply doesn't
> make sense. This is my last comment on this approach.
>
> What is possible is:
>
> self add: (Kernel-Array new: 4).
>
> Here, #- is a message.
>

Again, discussion downs not to about how namespaces should behave, but
to choosing appropriate and  conventional syntax for it. Personally, i
don't think its really matters.
Please, people, lets focus on more important things, if you don't want
to flame this topic, like in previous 'pipe syntax'.



--
Best regards,
Igor Stasenko AKA sig.

Period works okay if Period followed by whitespace is an expression separator, and period followed by a printable character can be part of a name.

What's a variadic message?

I'm not sure what the status of underscores are. Currently I think they're still a hack for the back-arrow in the squeak image, and from what I hear they are not accepted in Croquet? It is possible to free them up and make people use either a Unicode back-arrow :-) or :=.

Michael.

Hi

And its known from the ruby language. I like the :: notation
I went from ruby to squeak and I like both.

just my 2 cent
Enno

+1

On 9/18/07, [hidden email] <[hidden email]> wrote:
> 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.

Thanks... this is a really good find. Reading.

Gulik.

My implementation handles this fine. In this case, you'd have P1 containing N1::X (using Krampe notation) and P2 containing N1::Y. The import list of your code using X and Y would include P1 and P2 (import lists contain only other Namespaces, and Packages are Namespaces).

When your code contains the name "N1::X", then the compiler will search P1 (from the import list) for N1, then that N1 for X and find it (and continue searching to make sure the name isn't ambiguous). When your code contains the name "N2::X" then the compiler will search P1 (from the import list) for N1, search that N1 for Y, not find it, search P2 (from the import list) for N1, search that N1 for Y, find it and return it (and continue searching to make sure it isn't ambiguous).

Michael.