> >  Second, you don't have to put the registry-creator in
> > class QuicktimePlayer.  If I don't want my changeset merged in, then I
> > probably I shouldn't be mucking with the central initialize method.
> > That doesn't stop me from putting it somewhere else.
> 
> Very true.  So you can create a dummy class 
> (QuicktimePlayerFlapService) whose sole purpose is to perform that one 
> registration.  I don't have a problem with this, but I think that if 
> we're going to go that way we should formalize the approach and have 
> some direct support for it (like have Adam's Registry class search 
> through Service subclasses during its "pull" phase or something).
> 

There would be no searching, actually.  The registry gets created the
same way that any other resource is created for the class or package,
typically with #initialize methods.


> 1. I would like a registration to be something that can be expressed 
> atomically in a Smalltalk versioning system.  Two distinct 
> registrations (eg registering QuicktimePlayer with the FileList and the 
> world menu) should be represented as separately versioned elements.
> 
> 2. All the Smalltalk versioning systems that I know about (changesets, 
> ENVY, StORE, Monticello, etc) have a very limited set of elements that 
> they support: methods, classes, and maybe packages or groups of 
> packages.  To satisfy 1, a registration needs to be represented by one 
> of these elements.  A package per registration would be ridiculous; 
> realistically, we're looking at classes or methods.

It just seems weird to make methods be something other than methods.  If
package managers only handle methods, then lets give them plain old
methods to handle, i.e. selectors plus executable code.  If you are
willing to extend the package manager to handle annotations, then it
should be just as easy to extend the package manager to handle
registries or whatever other kind of elements a package might include
besides code.


> 3. Although a Registry can be notified when a class or method is added 
> to the system, most classes and methods will not be pertinent to the 
> registry.  It needs some way of determining which of these elements 
> apply to it, and it needs to do this safely (without, say, invoking 
> every method that comes in or instantiating every class).  It thus 
> needs some way of interrogating these elements.

After this point we've already diverged completely.  If you want to
attach the information to methods then annotations are great.  It just
seems like a weird thing to attach to a method.  I'd rather see either a
plain old entry in the package object, or plain old executable code in
some place that will get executed.  After all, we already need to solve
the general problem of running post-installation and pre-removal code
for packages, and it would be nice to solve the general problem of
having stuff other than code in a package.


-Lex