Hi!

> goran at krampe.se writes:
>> Lex Spoon <lex at cc.gatech.edu> wrote:
>> > Just to toss in my votes:
>> >
>> > 1) I am not sure that SM::Package is an improvement over SMPackage.
>> > It does not look like a large improvement, anyway.
>>
>> Not sure what you mean with "improvement". Visually?
>
> The onus on the proposer to say how this is an improvement.  Thus far
> I do not see it.

I am trying my best. :) I just wondered what you meant.

> I see factors in each direction that are close to a wash.  Visually it
> is uglier, IMHO, though it is a matter of taste.

Again, you would see these colons very, very rarely:

- In the class definition, as the class name.
- In methods referencing a global (=class mostly) where there are multiple
namespaces defining it, AND where the method itself is NOT in one of
those.

IMHO the above boils down to quite few places, especially since we also
IMHO would simply use Smalltalk as the namespace for all of the "basic
image".

So to reformulate the above bullet - you would only see qualified names if
a method in package A references a class in non basic package B which is
also defined in another non basic package using another namespace.

> Regarding ambiguity,
> it has the advantage of decreasing ambiguity, but it pays two
> characters per name to accomplish this, and I am not sure it adds much
> in practice.  In practice, the prefix is almost always all the leading
> capital letters except the last; the only exceptions I can think of
> are classes with protocols in their name (e.g., HTTPSocket).

Again, it only "pays" those colons on very few occasions IMHO. Both
regarding typing and reading.

> Aside
> from that, if you are going to spend two characters, can't you just as
> well add two *meaningful* characters, e.g. SqMp instead of SM?  This
> would appear to disambiguate even further.

Of course, I don't think I was the one that introduced the SM:: example in
this thread (I just kept using it) - I would typically use SqueakMap:: I
think.

> The tool benefits you have proposed are interesting but tricky, and
> are not a clear win.  They are especially tricky when you consider
> code appears in places outside of the normal browsers.  This happens
> all the time in Smalltalk....

If you do not do anything with the tools - then you simply see the
qualified names just like you see prefixed names today - or in other
words, you see some :: here and there and a bit longer prefixes. It
doesn't seem like too much of a pain IMHO.

>> > 2) A general hierarchy is an improvement over one-level.  If you have
>> > a project with 1000 classes in it, then you need multiple namespaces
>> > within your project, and you want to group them under an umbrella
>> > identifier of your project.  Without hieriarchical names, you will
>> > have to invent a prefix for all your namespace names....
>>
>> I actually disagree. I don't think you need multiple namespaces if you
>> have 1000 classes in the *same Project*. 1000 classes doesn't equal such
>> a large team in practice - perhaps 10 developers? Not that hard to keep
>> names unique IMHO. Remember that this isn't java - we don't need
>> "namespaces" just to organize our classes - we have Categories for that.
>
> You are agreeing we should have sub-categories, but proposing that we
> should accomplish this by having two different kinds of categories in
> the system.  Isn't that a pity, though?  Why not stick with one
> categorization scheme for names?

Ehm, we *already* have this IMHO. We have categories and we have prefixes.
Sure, we could do as Todd says and give Categories a semantic meaning and
skip the prefixes - but it would IMHO cause "too many" namespaces, since
we then would use them for organization and not ONLY to maintain unique
collections of names.

As I have said, I think only one namespace per Project/Group is enough.

> We currently have a single categorization scheme.  It appears
> practical to evolve that existing scheme into a *single* scheme for
> using hierarchical names to disambiguate.  Given this practical
> strategy as an ultimate goal, it seems a pity to move in a different
> direction.

Well, I am not sure. I think having too fine granular namespaces is a
problem. Then we are ending up like Java where they use the "namespaces"
they have mainly for orgaisation causing thousands and thousand of
"islands".

IMHO one of the strengths behind Categories is in fact that they ARE non
semantic (disregarding PI).

> Overall, it is inevitable that some of the feel Frank describes is
> going to get worse when we add hierarchical names of any kind.  Let us
> try to have a clear win before we adopt something that has these
> definite minuses.
>
> -Lex

Well, as I have written a few times now I don't have any high hopes for my
solution getting adopted, even though people keep happily using it in
"emulation mode" all the time (prefixing).

I will probably refine it and try it out a bit myself - mostly because I
am interested in the feel of it - but since the resistance is so strong I
have no energy "fighting" for it more than I have already done - ending
this thread will be the last of it I guess.

regards, Göran