Registries
ducasse
ducasse at iam.unibe.ch
Wed Nov 5 09:08:54 UTC 2003
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
>
>
More information about the Squeak-dev
mailing list
|