That's why I almost always override isVisible like
@Override boolean isVisible() {
return super.isVisible() && myVisibilityConstraints;
}
Thus I can go for both approches (push and / or pull state).
Maybe this could be added to the Javadoc of isVisible ?
Just my 2 cents,
Antoine.
Matthijs Wensveen wrote:
Martijn Dashorst wrote:
On Mon, Jun 16, 2008 at 3:48 PM, Matthijs Wensveen
<[EMAIL PROTECTED]> wrote:
A little off-topic: It scares me a little when core developer make bold
statements like: "setters are evil" and "I wouldn't mind final was the
default in java". Maybe I'm just being paranoid here...
Why? Are we not allowed an opinion?
Why off-course! Am I not allowed to be scared? ;P
And from an OO point of view, I
can see how setters break encapsulation: they expose the internal
state of an object. In the case of setVisible this is exacerbated
because the semantics of the following are vague:
Label l = new Label("l", "foo") {
@Override boolean isVisible() { return false; }
};
l.setVisible(true);
add(l);
So either you'd want final to be the default, or you'd consider
setters evil. :-D
Hehe. Maybe in that case you should override setVisible as well to throw
an UnsupportedOperationException?
I disagree that you expose internal state. It's hardly internal when
there is a public setter. But I agree that it is often very useful to
override the getter (isser for booleans?) when there is a hard
dependency between the component visibility and some other state. As I
said: it's good to have choice.
Martijn
--
Antoine Angénieux
Associé
Clinigrid
5, avenue Mozart
75016 Paris, France
+336 60 21 09 18
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
