What's the biggest criticism of Tapestry? The steep learning curve. One of the factors that drive the steep learning curve is the the basic design, the earliest, most primordial parts, was inheritance driven, rather than aggregation driven.
This reflects my early OO experience in Objective-C for NeXTSTEP; with no garbage collection, object allocation was the enemy, and fewer objects made sense. In the past 8 - 9 years that I've been doing Java, I've seen a progression away from inhertance and towards aggregation. I often say "aggregation trumps inheritance". What are the problems with inheritance? When you extend an object, you have to decide, on a method-by-method basis, which methods to override and, when overriding them, whether to call inheritted implementation or not and when. That means to properly subclass, you need to understand too much about the class from which you extend, and in a complex environment like Tapestry, you need to know too much about how that class fits into the overall picture. This is exactly what I'm trying to avoid going forward, with new code. Nowadays, I grind my teeth everytime I have to say "if you have a template extend BaseComponent, if not, extend AbstractComponent". In many aspects of Tapestry, and HiveMind, I've used the attitude that you start strict, then ease up those restrictions later. Without very firm constraints, you have a chaotic environment with very little ability to bring order to it. Better to start from an orderly, perhaps overly so, design and finds ways to "optimize". Thus, you do from a pure HTML/XML/Java seperate into Tapestry 2, to implicit components in Tapestry 3, to annotations and less XML in Tapestry 4. Using final is like that; keeping properties private is like that. Less exposure, less "surface area" to the API. You can always loosen that visibility restrictions later, or allow a method to be overriden later, but once you let the djinn out of the bottle, it's impossible to put him back in (without breaking backwards compatibility). Now, a lot of my concerns, as a framework author, are different from your concerns, as application authors. When you own the implementation and useage of your code, you can be much more flexible, without fear of hamstringing yourself. But with a Tapestry, code that gets released and has its own life far away from the Tapestry Team, we have to be very, very careful. In fact, this is why I'm focusing my efforts on an entirely new codebase for Tapestry5. I'll be finally keeping internal and public APIs seperate. There'll be very little API in Tapestry5 beyond a few annotations. All the implementation details will be on the "other side of the fence", free to evolve from release to release without affecting existing application code. This should finally address the issues that keep the Tapestry major (and minor) release numbers incrementing too quickly. I hope to see a 5.0.57 some day! On 4/9/06, D&J Gredler <[EMAIL PROTECTED]> wrote: > If you get a second, I'd like to hear where and why you've begun to use > "final". > > Regards, > > Daniel > > On 4/9/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > > > > > What I haven't done in Tapestry or HiveMind, but am starting to do in > > Tapestry5, is to use "final" much more liberally. But that's another > > discussion. > > > > > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
