ducasse at iam.unibe.ch
Wed Nov 5 07:58:46 UTC 2003
I thought more about the problem and I'm still not convinced. I still
do not understand the difference
Tell me if I'm wrong
>> I had a brief look and this is a good start. I really think that we
>> need this kind of architectural
>> support to avoid all the hardcoded mess. I have the impression that
>> the annotations are not really required we can simply use the class
>> initialize way for now as we do it in FileList.
> Stef, you may well be able to come up with another solution than
> annotations, but class initialize methods are not it, for a very
> simple reason: you can only have one #initialize method per class.
> This means that:
> - I can't extend your package with a new registration without
> modifying one of your methods
If in application reader I want to have a new registration for the
video class. I just in the reader application declare a new registry
entry for Video in the Registry entry.
> - 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.
> - The registrations cannot go in the same method category as related
> methods, especially if there are multiple kinds of registrations for
> the same class
> And probably lots of other problems along the same lines.
> We could of course allow multiple #initialize methods, but then we'd
> have to mark them as such, and how would we do that? Well, we could
> use method annotations... ;)
More information about the Squeak-dev