Future of Skins

[Tomas Mikula]

On Tue, Jan 7, 2014 at 4:26 PM, John Hendrikx <hjohn at xs4all.nl> wrote:

> On 7/01/2014 14:50, Tomas Mikula wrote:
>
>> Interesting ideas. I'm wondering, do you switch skins often enough that
>> you are worried about performance (and thus care about reusability of
>> skins)? Because I don't see how reusability of skins saves you lines of
>> code - whether the code is in the constructor or in the initialize()
>> method, it is there somewhere. In my opinion, reusing objects is more
>> complicated than creating fresh instances and the only justification for it
>> is performance.
>>
>
> To address your last point first, if you already are required to write a
> proper dispose method, then fresh instances should be just as easy/hard to
> write as reusable ones.  Everything is already in place, just rename the
> constructor.  Of course, if you did not write a proper dispose method, then
> your object will stick around or cause other trouble.  With fresh instances
> you won't notice this so readily -- in JavaFX for example, the problem of
> having objects that are no longer actively reachable through the
> SceneGraph, but are still participating in Event handling (because they
> registered non-weak listeners) can be a nice source of surprises.  With
> reusable objects, you'll notice the bugs in your cleanup code likely the
> first time you reuse it.
>

With a non-reusable skin, dispose is pretty much just removing the
listeners. With a reusable instance, I suspect there is more work to reset
the state of the instance (e.g. removing children, or, if you were
concerned about performance, returning them to a pool of objects). So I
would argue fresh instances are never more complicated than reusable ones,
while the opposite is true only in simple cases.


> Anyway, for me, making Skins reusable makes them easier to use with
> bindings,


 My understanding of skins is that they are the view of the MVC pattern and
that the rest of the application should not depend on the particular
implementation.


> and it ofcourse saves creating a factory.  I see the "skin" of an object
> as the same as say its background color.  There is no reason (anymore I
> think) that one should be treated so differently from the other.
>

One outstanding difference is that a skin is stateful, while a background
color is stateless (immutable). Thus you can use the same instance of
background color for many controls, but you cannot do that with skin
instances. In this respect, a skin provider is a better analogy to
background color (you can use the same skin provider with many controls).


>
>    private final Skin someExistingSkin = new SkinA();
>    private final Skin someExistingSkin2 = new SkinB();
>
>    void changeToSquareLook() {
>       myControl.setSkin(someExistingSkin);
>    }
>
>    void changeToRoundLook() {
>       myControl.setSkin(someExistingSkin2);
>    }
>
> vs.
>
>   private final SkinFactory skinFactory = new SkinFactory() {
>      public Skin createSkin(Control control) {
>          return new SkinA(control);
>      }
>   };
>
>   private final SkinFactory skinFactory2 = new SkinFactory() {
>      public Skin createSkin(Control control) {
>          return new SkinB(control);
>      }
>   };
>
>   void changeToSquareLook() {
>      myControl.setSkin(skinFactory.createSkin(myControl));
>   }
>
>    void changeToRoundLook() {
>      myControl.setSkin(skinFactory2.createSkin(myControl));
>    }
>

With lambdas, the skin factories become one-liners, yielding the same total
number of lines.


>
> It's not really about performance, but ease of use.  The binding case
> requires a ChangeListener instead of just bind().
>
>
>  I agree with you on the problem of separation of skin initialization from
>> setSkin(). Another way to address this could be deprecating the original
>> setSkin() method and introducing
>>
>>     setSkin(SkinProvider<C> skinProvider);
>>
>> where SkinProvider is a SAM interface and thus the above method could be
>> called like this:
>>
>>     setSkin(control -> new MySkin(control));
>>
>> I know this defeats reusability of skins altogether, so you (and others)
>> may disagree.
>>
> Maybe if there was a "skinProviderProperty"... then I could bind to that
> atleast.  Still introduces lots of factories (or functions).
>
> --John
>
>
Furthermore, neither the current state nor your proposal prevents you from
doing this:

Skin<MyControl> skin = new MySkin();
myControl1.setSkin(skin);
myControl2.setSkin(skin);

My proposal does not allow you to write such code.

Best,
Tomas