Nice!
Johan Compagner wrote:
Igor already has plans to fix/change that
something like isVisible and setVisible both final
and then you can override visible() that we check for you in the isVisible()
method (but first also we check our own flag)
so both setVisible() and your overridden visible() are working fine. (and we
can test other stuff like isVisibleInHierarchy and so on.
johan
On Mon, Jun 16, 2008 at 11:52 PM, Matthijs Wensveen <[EMAIL PROTECTED]>
wrote:
Of course I have a few things to learn, and I hope I never stop learning.
The article you provide is interesting.
My opinion is that for domain entity objects, getters and setters are
certainly not evil. For classes that are more service-like, getters and
setters could be useful but should be considered well. In case you choose
not to have a getter and a setter one should be extra careful when choosing
method names. I usually expect a setVisible method when there is also an
isVisible method. Immutable classes, or classes with read-only properties
can choose to only provide a getter for some properties. But if a method
like isVisible is intended to be overridden something like public boolean
visible() might be better. But I guess this is also a matter of style and
taste.
As for Component.set/isVisible, I like that I can do both, even if it gives
me the possibility of ambiguous code like new Component() {isVisible()
{return true;};}.setVisible(false) or something like that (it is actually
not ambiguous at all of course, but you do have to read extra careful). So
whatever reason you (core devs) originally had for providing a setter, I am
thankful for that.
Matthijs
Jonathan Locke wrote:
i think you may have a few things to learn and it is not exactly
controversial to prefer immutability or encapsulation... setters break
encapsulation and i think it is safe to say decades of experience with
object systems is on my side, including industry luminaries like:
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
Matthijs Wensveen-2 wrote:
Jonathan Locke wrote:
true.
in the isVisible impl you could lazy-init cache a transient Boolean
until
end request where you set it null.
setters are evil.
..but it's good to have choice. *And* setVisible is not a normal setter,
because it returns the component, which makes it easy to add an initially
invisible component like: add(new Label("profanity",
"[EMAIL PROTECTED]").setVisible(false));
Also, with is/setVisible you van use the component with a propertymodel
to have some other component toggle the visibility of another component.
This way you have the best of both worlds.
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...
Matthijs
egolan74 wrote:
Yes but ...
isVisible may be triggered several times, while setVisible should only
be
called once (say if I do it only once after creating the component).
Usually I prefer the state driven way, but what if the logic has a lot
of
overhead?
Jonathan Locke wrote:
isVisible is generally better imo because it is state driven. if you
push instead of pull, the state can get stale.
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
