SimpleStyleable<Foo>Properties API Questions
danno.ferrin at shemnon.com
Thu Mar 14 10:56:07 PDT 2013
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>
>> > 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
>> > 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.
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
More information about the openjfx-dev