I'm not so involved with the project as you folks.... but as a user ....
I agree with Kent. my opinion is that naming conventions are not a welcome additions here. Annotations are not so hard to explain, especially as they are used more and more. method name should state what it is doing, and annotation is perfect here to say when in render phase it should happen. Clean code is a bliss, why enable people making it ugly if you don't have to ? Davor Hrg On 12/21/06, Kent Tong <[EMAIL PROTECTED]> 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. 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]
