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: > Gili, > > 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 :) > > Eelco > > Gili wrote: > > >On Mon, 03 Jan 2005 09:35:26 -0800, Jonathan Locke wrote: > > > > > > > >>nope. final stops people from using extension points we haven't fully > >>thought through. so it's the default for every class and method. in > >>fact, this should have been the default in java. > >> > >> > > > > Heh, C++ uses such mindset. The Java designers made an explicit > >decision in 1.0 to make the opposite the default and I happen to agree > >with them. Everything should be extensible by default and no problems > >should occur so long as you follow objected-oriented design -- that is, > >your extension must satisfy all contractual requirements of the > >superclass. Frankly, this would work better if Java had design by > >contract, but it does not yet. > > > > From my discussions with the Java guys, the only reason final > >even exists (in the context of methods and classes) is for security > >reasons (and in the past for performance reasons). It was never meant > >as a mechanism for artificially controlling all future changes. > > > ><my 2 cents> > > When I am designing my own frameworks, I let people make > >whatever extensions they wish and if they somehow run into problems > >because I forgot to expose some precondition/postcondition then I > >tighten my documentation. I think this mentality helps open-source > >projects where you don't want everyone double-checking with everyone > >else. Right now we're five people working together and double checking > >everything. In the future you might have some other project depending > >upon ours and extending it for their own use, or even five of them. We > >will simply not able to micromanage everything, nor should we try to. > >We still get to retain control over our own code, but we shouldn't try > >to control other people's code... > ></my 2 cents> > > > >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 > ------------------------------------------------------- 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
