SimpleStyleable<Foo>Properties API Questions

[Danno Ferrin]

Rather than deriving from Simple and adding the Styleable implementations,
it would derive from Styleable and add the Simple implementations.  I'll
try and get a patch together tonight demonstrating it.

But the advantage then is that I am more likely in my code to expose
StyleableDoubleProperties and implement them with
SimpleStyleableDoubleProperties.  Then at a later date, if I need some more
exposure into the styling life cycle I can change the backing impl.  The
advantage over that and, say StyleableProperty<Double> is that the generic
isn't subject to erasure and reification contortions.  Who would ever
expose SimpleDoubleProperty in their API?  But I do see people exposing
StyleableDoubleProperty in an API.

On Thu, Mar 14, 2013 at 9:20 AM, David Grieve <david.grieve at oracle.com>wrote:

> I'm sorry. I must really be misunderstanding what it is you are
> suggesting. I don't know how you can have SimpleStyleable<Foo>Property
> extend both Styleable<Foo>Property and Simple<Foo>Property.
>
> On Mar 14, 2013, at 10:15 AM, Danno Ferrin <danno.ferrin at shemnon.com>
> wrote:
>
>
> >
>
>> > 2.  Why does it extend from Simple<Foo>Property instead of
>> > Styleable<Foo>Property?  Just an implementation convenience?  I think it
>> > would be more valuable to extend from the Styleable property than the
>> > Simple property, since simple only adds implementation but styleable
>> adds
>> > implementation for a new interface.  I see myself adding more
>> > StyleableDoubleProperties that are backed by a Simple varient than a
>> > SimpleDoubleProperty backed by the styleable variant.
>> >
>>
>> Because we want SimpleStyleable<Foo>Property to be a Simple<Foo>Property
>> _and_ a StyleableProperty. It is the only way to do it since
>> Simple<Foo>Property is a class and StyleableProperty is an interface. To do
>> it the other way around would require that the SimpleStyleable<Foo>Property
>> re-implement the entire Simple<Foo>Property API - <Foo>PropertyBase,
>> <Foo>Property, ReadOnly<Foo>Property and so on.
>>
>> I can understand that you want to be able to do 'StyleableDoubleProperty
>> foo = new SimpleStyleableDoubleProperty(FOO);'  But you can do
>> 'StyleableProperty<Double> foo = new SimpleStyleableDoubleProperty(FOO);'
>>
>>
> I want it to be a Simple<Foo>Porperty and a Styleable<Foo>Property, you
> missed the <foo> on the styleable, very important.  Both of these classes
> derive from <Foo>PropertyBase, so they both save a lot of overhead there.
>  It is the implementation in the specialization where the horse trading
> occurs. The implementation overhead for Simple<Foo>Property is 3 one-line
> constructors, two fields, and two one line methods for those fields.  The
> implementation overhead for SimpleStyleable<Foo>Property is 4 constructors,
> 5 methods, and a total of 8 lines, and two fields.  Really slightly more
> code duplication and work is being done for the current hierarchy.
>
>
> --
> Danno
>
>
>


-- 
There is nothing that will hold me back.  I know who I am....
I remember wher I came from, and I feel stronger for knowing.
Zane, Ninja of Ice.  Ninjago S01E07