Igor Vaynberg wrote:
On 7/7/07, *Eelco Hillenius* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
two points:
this is relatively new, i think it made it in just before
1.3-beta1 or
somewhere there
I think it's been in there for quite a while. But as I
Of course, if Java had compile-time MyClass#field syntax, then that
could enforce the visibility and everyone would be happy.
+1!
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version
i am als -1 on removing this. it won't help a bit
also this feature is already in the PropertyResolver from november last
year.
So already 8 or 9 months in the code base.
johan
On 7/9/07, Matej Knopp [EMAIL PROTECTED] wrote:
I'm a strong -1 on removing access to private fields. This wouldn't
On 7/7/07, Kent Tong [EMAIL PROTECTED] wrote:
I've never said saving typing is always bad. As I said in another post,
saving typing at the cost of static type checking sometimes is a
justified tradeoff (eg, regex). Just that I've never seen that being
done at the cost of exposing
I'm a strong -1 on removing access to private fields. This wouldn't
really change anything. When someone wants to access private fields,
he/she will do that, with or without PropertyModel.
-Matej
On 7/8/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
On 7/7/07, Kent Tong [EMAIL PROTECTED] wrote:
We could do the restriction, but then the question will be how
predicable and confusing this behavior will be.
-Matej
On 7/8/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
On 7/7/07, Kent Tong [EMAIL PROTECTED] wrote:
I've never said saving typing is always bad. As I said in another post,
On 7/7/07, Kent Tong [EMAIL PROTECTED] wrote:
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
Martijn Dashorst martijn.dashorst at gmail.com writes:
Like it or not, propertymodels already break encapsulation, the law of
demeter and refactoring without having to resort to private accessors.
So if you go all OO, these things should never be used, especially
since there is a perfect OO
Igor Vaynberg igor.vaynberg at gmail.com writes:
i disagree completely. the most common usecase for this is for components
to access their own private fields via property model.
class namepanel extends formcomponentpanel {
private string first;
private string last;
namepanel(..) {
On 7/6/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Well, just take a look at the project we are working on together. Such
fields mostly have getters and setters :)
two points:
this is relatively new, i think it made it in just before 1.3-beta1 or
somewhere there
you didnt know about it, so
On 7/7/07, Kent Tong [EMAIL PROTECTED] wrote:
Martijn Dashorst martijn.dashorst at gmail.com writes:
For a Java bean class, most likely every field is to be read sooner
or later. According to this argument of speed, we should simply
use public fields for all Java bean classes? As I said
On 7/7/07, Kent Tong [EMAIL PROTECTED] wrote:
Would a specialized PropertyModel subclass (eg, PrivateFieldModel) do
the job?
you say you are concerned with abuse, but what would this subclass
solve? those who want to abuse can then just use privatefieldmodel to
do so.
if you are really
two points:
this is relatively new, i think it made it in just before 1.3-beta1 or
somewhere there
I think it's been in there for quite a while. But as I never depended
on it, I wouldn't know.
you didnt know about it, so of course you would be writing
getters/setters
Heh. My point is that
On 7/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
two points:
this is relatively new, i think it made it in just before 1.3-beta1 or
somewhere there
I think it's been in there for quite a while. But as I never depended
on it, I wouldn't know.
you didnt know about it, so of course you
the point isnt that they are wicket-specific. the point is that they are
reusable, so if i take a component you wrote and put it into a panel i am
writing i dont want to put it into an inconsistent state by calling some
setter i shouldnt. ive done that before and had to go look into the source
This is fine and acceptable. What I'd like to find out is what we should
tell people about this feature:
1) You should always use it.
2) You shouldn't use it as it is going to be deprecated.
3) You should use it only in cases like your NamePanel.
I put a note/ warning in
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
(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
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
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
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
i didn't say that's fine. it's clearly not. i was just pointing out
there's
another side to this argument because java's protection attributes are
so coarse grained. by not supporting this feature, some classes which
otherwise would have all implementation details private would be forced
i didn't say that's fine. it's clearly not. i was just pointing out
there's
another side to this argument because java's protection attributes are
so coarse grained. by not supporting this feature, some classes which
otherwise would have all implementation details private would be forced
On 7/6/07, Eelco Hillenius [EMAIL PROTECTED] 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
i disagree completely. the most common usecase for this is for components to
access their own private fields via property model.
class namepanel extends formcomponentpanel {
private string first;
private string last;
namepanel(..) {
add(new textfield(first, new
25 matches
Mail list logo
