On Nov 5, 2003, at 7:01 AM, Lex Spoon wrote:

> 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.  :)

Absolutely, but it makes the maintainer's job much easier when the 
various changesets he has to sort through don't clobber each other.

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

Very true.  So you can create a dummy class 
(QuicktimePlayerFlapService) whose sole purpose is to perform that one 
registration.  I don't have a problem with this, but I think that if 
we're going to go that way we should formalize the approach and have 
some direct support for it (like have Adam's Registry class search 
through Service subclasses during its "pull" phase or something).

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

Well, I basically agree - certainly I'm with you on the 
config-files-are-evil count.  Given that, let me try to present some of 
my rationale for wanting method annotations, partially so that I can 
understand them better, and also so that someone can suggest a better, 
more dynamic alternative:

1. I would like a registration to be something that can be expressed 
atomically in a Smalltalk versioning system.  Two distinct 
registrations (eg registering QuicktimePlayer with the FileList and the 
world menu) should be represented as separately versioned elements.

2. All the Smalltalk versioning systems that I know about (changesets, 
ENVY, StORE, Monticello, etc) have a very limited set of elements that 
they support: methods, classes, and maybe packages or groups of 
packages.  To satisfy 1, a registration needs to be represented by one 
of these elements.  A package per registration would be ridiculous; 
realistically, we're looking at classes or methods.

3. Although a Registry can be notified when a class or method is added 
to the system, most classes and methods will not be pertinent to the 
registry.  It needs some way of determining which of these elements 
apply to it, and it needs to do this safely (without, say, invoking 
every method that comes in or instantiating every class).  It thus 
needs some way of interrogating these elements.

4.  Because every class object has a different metaclass, they respond 
very well to interrogation - you can very easily provide metadata for a 
class, in a very flexible, dynamic way, by implementing class-side 
methods.  Unfortunately, this isn't true for methods - all method 
objects belong to the same class, CompiledMethod.  The only way they 
differ is through their instance data, but by default it's not very 
useful, unless we want to draw conclusions from the bytecode or source 
code.

5.  Annotations provide a way of introducing more meaningful instance 
data into method objects.

Now, you can dispute point 1, and say that everything can just go into 
a monolithic #initialize method; I hold that this doesn't scale, but 
the only way to really know will be to try it.

I f you accept point 1, you can dispute point 2: perhaps Smalltalk 
versioning systems *should* know how to version other kinds of 
elements.  These could be named load scripts (like being able to have 
multiple initialize methods), or entries in a pool dictionary, or just 
some new "registration" element.  I'm certainly open to proposals along 
these lines for Monticello.

You could also address point 4 - maybe there should be a way to specify 
a different class for a method?  Can we extend changesets to support 
"!FooClass methodsForCategory: 'bar' methodClass: MyCompiledMethod !"?  
Perhaps that would be preferable to static annotations.  Or, you could 
take the lesson from point 4 that only classes can implement 
per-element behavior, and so each registration should be modelled by a 
separate class.

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

See? ;)

Avi