Cleaning up Control codebase - How to deal with StyleableProperty cast

[Jonathan Giles]

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.

-- Jonathan

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.
>>
>> Tom
>>
>> On 30.04.14 15:39, Tom Schindl wrote:
>>> Hi,
>>>
>>> On 29.04.14 14:35, David Grieve wrote:
>>>> I've found that this works:
>>>>
>>>>      final StyleableBooleanProperty prop =
>>>> (StyleableBooleanProperty)focusTraversableProperty();
>>>>
>>> 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.
>>>
>>> Tom
>>>
>