Hi avi

I said initialize because I was thinking in terms of changesets. Now 
imagine a world where we have package like envy, sotre or monticello, 
we do not have these problems because these registrations should be 
done when the application, packages are loaded.

stef

On Mercredi, nov 5, 2003, at 09:46 Europe/Zurich, Avi Bryant wrote:

>
> 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
>
>