"Chris Muller" <asqueaker at gmail.com> writes:
> For code-elements, I've always been interested in the idea of
> maintaining human-meaningful names by "dodging" name collisions
> dynamically.  For the most part, prefixes combined with our desire for
> slim images have carried us this far, but one should expect a
> name-collision eventually.  We can do what Java did, "use huge
> prefixes" but then there's still the potential for a collision.  When
> that happens, why shouldn't a dynamic system dynamically adjust it?

In practice, many Java developers are leaning away from using
DNS-based names, and instead simplying using a normal package name as
your prefix.  Certainly I do so when I'm adrift in Java land.

Note that if your top-level package names collide, then you have
problems anyway.  Your jar files are going to collide, and you will
have trouble registering on things like FreshMeat or SqueakMap.  Thus,
to share a package publicly, you already need to come up with a unique
name, and you can then use that name in the code as well.

Which, by the way, Monticello already takes as a heuristic.  It's just
one step further to treat categories as naming prefixes.


Overall, I find myself envious of Java's global naming scheme.  Yes,
the DNS-based names are nonsense.  Leaving that aside, though, the
Java system is simple, it works, and we could have it, but we don't.

The main argument I see against the Java system is for small Squeak
images.  This might be a point of forking for Squeak: one way goes
towards miniature educational and experimental systems, while the
other leans towards serious software development.

Lex