Hi--

	I touched on this in the "Another perspective on modularity" thread,
but it seems to have gone unnoticed. :)

	How about making class *names* (that humans care about) and class
*identifiers* (that the tools care about) separate? I think it
simplifies much of the namespace discussion.

	Some background... For Squat's module system, I needed to be able to
refer to different versions of a single behavior. So, instead of using
the name of a class to identify the class, I use a UUID. (Since each
behavior is currently part of a class-metaclass pair, I use one UUID for
both of them, and store them in an instance variable defined by
Metaclass.)

	So. Once you have UUIDs available for identifying classes, instead of
textual class names, having multiple distinct classes with the same name
is no problem. You don't need to overload the "name" instance variable
(defined by Class) with namespace names. Instead, just make namespaces
be simple collections of class identifiers (UUIDs). Nest the namespaces
if you want, or not. :)  Give namespaces names and UUIDs too.

	When *storing* source code, use UUID storeStrings instead of class
names. When *viewing* source code, make the tools look up the UUIDs for
you, in whatever namespace structure you decide to use (think of it as a
kind of pretty-printing feature :). When *entering* source code, by all
means use whatever notation feels right (e.g., "Foo::Bar", as enabled by
the recently-posted Scanner changes), but there's no need to do a bunch
of string manipulation on class names. You can just keep on storing
unqualified text in the class names, as we've done up to now.

	Furthermore, when you're (finally ;) running methods that have made it
through the compilation gauntlet, the interpreter doesn't care about
class names or identifiers at all. It just wants there to be a valid
literal frame entry for each class used by a method (a valid object
*reference*). Unless your target audience has some weird mutant
interpreter, there isn't even a need to recompile source code again in
order to distribute your code. You can transfer methods directly from
one object memory to another, via remote messages over a network
connection. (If you insist on distributing a file, that file can be a
[small!] object memory snapshot that, when run, serves up your methods
over a local network connection :)

	Squat works this way ( http://netjam.org/squat ). You can transfer
methods that introduce new classes from one system to another without
ever referring to the class names, and without even invoking the
compiler. :)  I think people just assume that the mode of behavior
interchange consists of static files that get run through the compiler
("fileouts", mcz files, SAR files, etc.). This need not be so. (Of
course, you can have name/identifier independence whether you use static
files or not.)


	thanks,

-C

--
Craig Latta
improvisational musical informaticist
craig at netjam.org
www.netjam.org
[|] Proceed for Truth!