Well, I am viewing this as both a framework builder and as a framework user.
As a framework builder, yes I think it is a good thing to have things under control.
As a user, I benefit from a framework that is tight written because the API will probably clearer and more consistent. However, I've cursed many times on some of the JDK classes for being impossible to extend. And hey, I got valid use cases (from my point of view), but no way those private/ final stuff is out of there the next release. And I have heard complaints from Johan in this respect as well (I think when he works on http://www.servoy.com/).
IMO it should be a nice mix, and Wicket is a bit tighter than I would have build. But I'm probably just an idiot ;)
Eelco
Jonathan Locke wrote:
it's interesting to generalize this whole viewpoint. the reason we make
everything as private as possible is to encapsulate (this point leads to
the whole getters-are-evil discussion because those expose details that
might not need to be exposed). the reason we encapsulate is to reduce
dependencies on implementation details. the reason we try to reduce
dependencies is to /reduce our commitments to framework users/.
in some sense, i think the whole point of OO programming is to control access. everything should be as final and as private as possible until a commitment to a wider access is /well understood/. people cannot write software that works in the first place. opening things up architecturally before extensibility is carefully managed is a recipe for an even bigger disaster. see windows!
On Tue, 4 Jan 2005, Eelco Hillenius wrote:
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
