Squeak and Namespaces

Lex Spoon lex at cc.gatech.edu
Sun Dec 3 12:34:30 UTC 2006


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 see factors in each direction that are close to a wash.  Visually it
is uglier, IMHO, though it is a matter of taste.  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).  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.


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




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

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.


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




More information about the Squeak-dev mailing list