Hi Frank--

> I think Craig's point is that that name doesn't matter: what you call
> a Foo in your image I might call a Foozle, even though it's the same
> class/method/whatever.

     That's not what I was going for, but yes, you could do that. :)
The more likely scenario is, for example, what you and I both call a
Socket now are different things, or what you call a Socket in 2011 is
different than what you called a Socket in 1996.

> ...could you expand a bit on the modularity aspects of Spoon? I get
> the versioning, and the lack-of-name-prevents-name-clash, but I don't
> see yet how it addresses controlling dependencies between large
> chunks of code.

     What questions would you like to be able to ask of the system? In
the meantime, I'll try to illustrate what's possible.

     First, some background. Every method in the system has a
corresponding method edition. The method edition has a collection of
markers for each literal in the method. For a literal which is a
reference to a class, the literal marker can get the ID of the class.
The class ID uniquely identifies the precise class object that the
method is expecting to use, as well as the author of the definition of
that class. Method editions are similarly identified by method IDs.
Modules are essentially collections of method IDs, and may have other
modules as prerequisites. Every method in the system is described by a
module. Every module is described by an ID, and has a
search-engine-indexable URI describing how to get it.

     Now, some possibilities. For any set of modules, you can enumerate
the IDs of all the classes used by all the methods in those modules. For
any live class object, you can find the known modules refer to it (or
any earlier or later version). For any author, you can find the known
modules that use their work. You might use that information to decide
the component methods of a module, and its prerequisite relationships
with other modules.

> It's my firmly held opinion that it's better to open your mouth only
> to change feet - as long as you learn something each time - than to
> never open your mouth.

     :)

> So, by analogy, I think it's better to implement things, even
> brain-dead things that you have to rip out/apart - as long as you
> learn something each time - than to sit and talk about what the
> perfect system might look like, that would please everybody all the
> time.

     Just to be clear, I am implementing this, although I have to do it
in precious little stretches of so-far-unpaid time. And I'm not trying
to please everyone all the time, although I would like design feedback.
Finally, I've implemented and thrown away a bunch of other things to get
here. A few folks have tried them out and commented, too, and I'm very
thankful for that.


     thanks again,

-C

--
Craig Latta
www.netjam.org/resume
+31  06 2757 7177
+ 1 415  287 3547