to give a pseudo-code example of what i mean, imagine something
like this:
hibernate wicket int getValue() { ... }
where hibernate and wicket are attributes that expose the method
only to org.apache.wicket.** and hibernate's package. this sort of
thing is possible in scala, but not java.
in any case, java is broken here and so the choice on this feature is
not clear. maybe the best thing is to make private introspection an
application setting that is off by default? this might be a good idea
for the sake of security anyway.
Jonathan Locke wrote:
>
>
> 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.
>
>
> Kent Tong wrote:
>>
>> Hi,
>>
>> Wicket 1.3 is now allowing PropertyModel to access private fields of the
>> target object. However, I am not sure if this is a recommended practice.
>> There are basically two supporting reasons for this feature:
>> 1) No need to generate boring getters and setters.
>> 2) Hibernate & Spring also support this.
>>
>> If we accept that 1) is a good reason for allowing private field access,
>> then according to the same reasoning, we should always make our fields
>> public and thus eliminate the need for getters and setters. As we are
>> not going that, so I believe 1) is not a sufficient reason.
>>
>> Looking into 2), Hibernate is trying to persist the *implementation* of
>> our class. Therefore, it may need access to its private fields.
>> Therefore,
>> it can be argued that Hibernate is in a special position to be granted
>> such special access. Even so, its official documentation recommends using
>> getters and setters
>> (http://www.hibernate.org/hib_docs/v3/reference/en/html/persistent-classes.html#persistent-classes-pojo-accessors).
>> However, I don't see why PropertyModel (or Wicket code in general) is in
>> such a special position. It is part of the UI and I don't see why UI code
>> should need access to implementation details.
>>
>> I don't know how Spring access private fields, so I can't comment on that
>> one.
>>
>> So, is this feature a recommended practice or just a backdoor for those
>> who prefer using public fields?
>>
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/access-to-private-fields-tf4038948.html#a11475016
Sent from the Wicket - User mailing list archive at Nabble.com.
-------------------------------------------------------------------------
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
