Avi Bryant <avi at beta4.com> 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.


Having a registry registry sounds fine to me, Adam.  But I share some of
Stef's feelings about the approach.  Let me elaborate.

Pragmattically, I think initialize methods will work out just fine.  The
issue you describe is unconvincing to me.  First, there should be a
Quicktime maintainer, anyway, who can keep a merged changeset available.
 If there's not one, then one of you, myself, and Julian needs to
volunteer.  :)  Second, you don't have to put the registry-creator in
class QuicktimePlayer.  If I don't want my changeset merged in, then I
probably I shouldn't be mucking with the central initialize method. 
That doesn't stop me from putting it somewhere else.

Aside from these pragmatics, though, there are philosophical issues.  I
freely admit I don't really completely get the impact of annotating
methods, but it feels suspicious to me.  For starters, I hope there is a
way to do it *without* method annotations, e.g.

	reg := Registry newNamed: 'MyRegistry'

That way the name can becomputed if necessary:

	reg := Registry named: (self class name)


Also, I worry that if we use the method annotations approach, at some
time in the future someone is going to hack in an alternative way on top
of it that is more dynamic, e.g. "if the first character of the string
is [, then evaluate the string instead of using it directly".  If we end
up doing that, then it seems we may as well have used plain old
Smalltalk code.

I guess in sum, method annotations seem like meta-code to me.  For
application information, it seems better to use our nice OO language
Smalltalk.  For comparison, consider the Java guys, who put all kinds of
things into XML files instead of into Java objects and then end up
coding all the time in half-baked XML formats.  If they decide they want
to insert code for something instead of writing out the text, they are
in trouble, because they've committed to using static XML instead of a
dynamic language.

But maybe I'm just used to the way things are and am not seeing it. 
It's very possible!



By the way, you mentioned marking multiple class initialization methods
using annotations.  That sounds very nice!


-Lex