On Nov 4, 2003, at 11:58 PM, ducasse wrote:

>> - Two patches both adding registrations to the same package will 
>> always conflict
> The annotation will not solve that. If there is a conflict one should 
> win or there should a way to resolve
> it. I do not see the solution with annotation. One should win so may 
> be this is the load order.

No, you misunderstood me.  Let me give you an example:

I introduce a QuicktimePlayer class that can read and play .mov files.  
In its class-side #initialize method, I register it with the file list 
so that it will show up as an option whenever you have a .mov file 
selected.

You think it would be useful to add it to the open menu, so you submit 
a .cs that modifies the #initialize method to register it with the 
world menu.

Meanwhile, Julian thinks it would be nice to have it in a flap, so he 
also modifies the original #initialize method to register it with the 
flaps system.  He submits a .cs for this.

Now, there's no inherent reason your change and Julian's change should 
conflict.  In fact, neither of them are really changes, they're simple 
extensions of the existing behavior.  However, because they're both 
forced into the #initialize method, they cannot both be loaded at once, 
and if I were merging the changes I would have to do it by hand.

With annotations, all three registrations - FileList, TheWorldMenu, 
Flaps - would be in separate methods, and would be completely 
independent.

This isn't a huge deal on a small scale - AFAIK we only have three 
registries currently in use in the image - but as the number of 
registries go up (and we want it to go up) this kind of problem will 
become more and more common.  I'd really like to see a better solution, 
whether its method annotations or something else we haven't thought of 
yet.

Avi