thanks I will digest it

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