Hi adam

> That's exactly the world I'm imagining.  But what is the mechanism by 
> which these registrations happen on load?

In envy you had an application that the application had
	three hooks that you could specialize: after loading, before unloading 
and a htird one I forgot.

with Parcel any class can have preload, postload, preunload, postunload 
action specified as block
that will be executed.

in Store you have nearly the same on packages and bundle.

> How are these registrations *declared*?  One possibility is through 
> annotations.  Another possibility might be through adding a class - 
> you could have a FileListService class, and the way to register a new 
> FileList service is by loading a subclass (with some kind of #isActive 
> method - there might be cases when you want the class loaded but the 
> service disabled).  Yet another possibility (probably my least 
> favorite) would be to do what SUnit does and have a special selector 
> prefix (#fileListServiceFoo).  But IMO it's, erm, imperative that we 
> have some kind of declarative specification of these registrations.  
> That's been my point all along.

I agree and understand. I think that the best with package would be to 
have the possibility to have methods that are special. Now if we do not 
have packages conventions a la SUnit are ok too.

> I don't see why you say that "we do not have these problems"; it seems 
> to me that the problem (of using #initialize) just gets highlighted.

Avi said thattwo guys may want to register both something and that only 
one method initialize is possible for example on VideoPlayer. Now by 
giving the responsibility to a package to do the resgitration:
	- either the package does the right registration, and two packages can 
both resgiter whatthey want
	(sure we can have conflict but there is no magic, one should win)
	- either the two guys communicate with the VideoPlayer maintainer and 
the registration is moved 	there.

a single initialize method on the VideoPlayer is not enough has it was 
in the FileList Registration.
So I agree with avi on this point.

>
> Avi
>
>