I haven't responded to this for the simple reason that it's a pretty damn clear explanation on the thoughts behind your API style. Thanks ! :)
On 4/9/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > 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] > > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://opennotion.com
