On Tue, 4 Jan 2005, Gili wrote: > > I've had the same (terrible!) experiences as Johan and the > frustration level was intense. It is practically impossible to extend > anything in Swing. It might be a flexible framework, but it is hell to > extend. > > I'm trying to address this in two ways in Wicket: > > 1) Hit you guys over the head when I see high coupling anywhere (which > is a major problem with Swing) > 2) Push you guys to be ready to make a method non-final or public on a > minute's notice if it passes a design review.
that's the best thing. > > The point is: either you promise to be on your toes or you make > it possible to extend the framework without you. The alternative is > hell. > > Gili > > On Tue, 04 Jan 2005 22:58:35 +0100, Johan Compagner wrote: > > >I didn't plan to have this discussion agian right now ;) > >But suddenly my name! > > > >Yes i am pretty much againts private /final ect. > >I thing the default java way is much better the the C++ way.. > >But by using final you THINK about it so you know you are making it non > >extendable.. And that is good > >If it is the other way around people just forget it. And then the user > >that wants to use it is screwed... > > > >I have so many examples for example in swing that i stumbled on so that > >i can't do my thing > >how i have to work around things like the private > >JFormattedTextField.setValue(Object,boolean) > >The stupid thing is that now with 1.5.0 they have implemented it the way > >i was trying to do anyway! > >(they added another boolean to skip the property change.. And that was > >one of the things i wanted to control > >But still i can't call that method from a sub class because it is > >private.... > > > >And there are more of these things. For examples NavigationFilters (how > >the caret walks through the textfield) > >You can get the default way but if you want it really like they do but a > >bit different? This is not possible > >Al hangs in package scope classes and call on each other. I did start to > >get it out of the package. Before i know > >it i had copied many classes of the swing text classes ect. And still it > >didn't work because it did call a special method > >of the formattedtextfield itself! So there is now way i can build my own > >Filter like they do because they have > >access to much much more. > > > >No i will never be conviced any other way everything as open as > >possible. Give me the choice what i want to do! > > > >johan > > > > > >Eelco Hillenius wrote: > > > >> 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 > >> > >> > > > > > > > >------------------------------------------------------- > >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
