Kent Tong wrote:
> Howard Lewis Ship <hlship <at> gmail.com> writes:
> 
>> I have a feeling that in many cases, people will prefer this approach to the
>> annotation approach.  Again, the methods can have any visibility, any return
>> type, and flexibility on parameters.
>>
>> Advantage for me:  when training, I can just say "name your method
>> beginRender()" ... I can later, if necessary, introduce the annotations.
> 
> Personally I find it just as easy to say "mark your method with 
> @BeginRender" without further explanations. Therefore, I don't see any 
> advantage of this approach. In addition, it has some disadvantages:
> 1) If the code is refactored (method name is changed), magically the 
> program will stop working.
> 2) If the programmer gets the method name wrong (eg, "startRender" 
> instead of "beginRender"), there is no early warning until the code 
> is run.

Bad me, I didn't read the whole thread -
my two cents: I would find it better to combine both, so one *may* use
annotations, or one *may* implement an interface, which gives you a
strong compile-time check...

Cheers,
Ron


> 3) The name of a method should express what the method does, not when
> the method should be invoked (eg, loadCustomer() vs beginRender()).
> Surely this can be easily worked around by having beginRender() call
> loadCustomer(), but this is bastardizing/overloading the purpose of
> the method name.
> 4) As a result of 3), the programmer cannot explicitly express his 
> intention to participate in the rendering phase. If later someone else 
> modifies the code, particularly if he is not very familiar with Tapestry 
> as Jesse pointed out, he may not know the significance of the method 
> name and may change it to better reflect what the method does. With
> an annotation it is highly unlikely that he will change it when it is
> something that he doesn't understand.
> 
> --
> Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to