the whole point is that we revisit each extension point as the need for it comes up. that way we can understand the use cases before we open up the pandora's box of extensibility. in many cases, i have caught problems this way in the past and i expect we will in the future.
what might be useful would be to put a line in the javadoc for each final method / class explaining what we are doing to those who aren't yet initiated in defensive programming. On Mon, 3 Jan 2005, Gili wrote: > On Tue, 04 Jan 2005 00:01:39 +0100, Eelco Hillenius wrote: > > >I agree with you in general. That /was/ exactely my point of view. > >However, I learned (from Wicket and other projects last year) that can > >be a good thing to actually limit yourself in order to come up with a > >tighter API. Just like poetry or music in a sense :) > > As long as we're a small group working on a beta product I > don't see this as a problem, but as soon as we hit 1.0 and others begin > layering on top of our framework it is something we should revisit. > > Gili > > > > ------------------------------------------------------- > 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 > ------------------------------------------------------- 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
