Cleaning up Control codebase - How to deal with StyleableProperty cast
jonathan.giles at oracle.com
Fri May 2 02:09:15 UTC 2014
I agree with David. Let's go that way and see where things end up.
As always, thanks Tom for being relentless in pushing this forward.
On 2/05/2014 1:27 p.m., David Grieve wrote:
> I don't have a strong opinion, other than a preference for having it
> done one way in all cases. So it seems
> (StyleableProperty<Boolean>)(WritableValue<Boolean>) would be the way
> to go.
> On 5/1/14, 12:25 PM, Tom Schindl wrote:
>> Hi Jonathan & David,
>> do you have any opinion on this? I would spend some time tomorrow to
>> bring down the warning count.
>> Maybe we should use the Styleable*Property cast when we control both the
>> API & implementation and reside to the more save
>> (StyleableProperty<Boolean>)(WritableValue<Boolean>) e.g. if we don't
>> e.g. because code is owned by the graphics module?
>> One could naturally look at this from another angle and say the Syleable
>> interface should have been shown in the API but I guess this not going
>> to change so we need to live with casts and the implementation detail.
>> On 30.04.14 15:39, Tom Schindl wrote:
>>> On 29.04.14 14:35, David Grieve wrote:
>>>> I've found that this works:
>>>> final StyleableBooleanProperty prop =
>>> Right i can confirm that.
>>> The problem is that we are then relying even more on the fact the
>>> upstream code does not change. If someone because of what ever reason
>>> decides to replace the StyleableBooleanProperty through a custom
>>> implementation StyleableProperty<Boolean> we get broken.
>>> In case of focusTraversableProperty() we are even crossing module
>>> boundaries in this case which worries me a bit.
More information about the openjfx-dev