> i think your argument is willfully slanted. generic manipulation and > persistence can be good reasons to reach into an implementation which > otherwise does not wish to expose properties or fields at all. i personally > prefer objects that keep all these details private. i would hope that > private accessor methods took precedence over private fields, but > given that, i think accessors in general are best avoided and it's not > necessarily good to expose private details simply to allow them to > be manipulated by a framework such as spring, wicket or hibernate. > that said, i think the real root of this problem is that java simply > fails to adequately express the protection attribute granularity that's > required here. being able to define new protection attributes that > limit the visibility of details based on the package (and possibly other > details like the thread group) of the caller would be the best way and > at the present time quite impossible.
As much as I agree with you in general, in this particular case, we provide direct access to private members where you normally (using straightforward Java/ no introspection) wouldn't have it. Theoretically, this could result in people accessing those members directly where they shouldn't. Even if you think that's fine, I doubt whether this is something Wicket should support. Eelco ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
