i imagine setVisible came from me. just because setters are evil and you
should avoid them when you can does not mean you should not use them when
you need them.
Matthijs Wensveen-2 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]
>
>
>
--
View this message in context:
http://www.nabble.com/isVisible-vs.-setVisible-tp17860615p17879066.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
