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
