Introduce DEFINE_ANIMATABLE_VALUE_TYPE_CASTS to replace manual toFoo() for animatable value

Introduce DEFINE_ANIMATABLE_VALUE_TYPE_CASTS to replace manual toFoo() for animatable value.

As a step to let toFoo() use DEFINE_TYPE_CASTS, this cl replace toFoo() for animatable value.
with DEFINE_ANIMATABLE_VALUE_TYPE_CASTS. To use DEFINE_TYPE_CASTS generates plenty
more helper functions which can detect bad type cast.

BUG=309516
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=160151

[gyuyoung-inactive, 2013-10-21 05:10:48]

Add tkent.

[tkent, 2013-10-21 05:25:03]

lgtm

[commit-bot: I haz the power, 2013-10-21 05:25:12]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/gyuyoung.kim@samsung.com/29543005/1

[dstockwell, 2013-10-21 05:27:45]

Is there a bug which explains why these changes are being made?

The implementation of DEFINE_TYPE_CASTS seems different to toAnimatableFoo which
asserts that the pointer is not null.

[tkent, 2013-10-21 05:30:37]

On 2013/10/21 05:27:45, dstockwell wrote:
> Is there a bug which explains why these changes are being made?

Unfortunately, no.

> The implementation of DEFINE_TYPE_CASTS seems different to toAnimatableFoo
which
> asserts that the pointer is not null.

toAnimatableFoo was wrong. WebKit/Blink convention is that toFoo should accept
null because it's a replacement of static_cast<>.

[gyuyoung-inactive, 2013-10-21 05:33:57]

On 2013/10/21 05:30:37, tkent wrote:
> On 2013/10/21 05:27:45, dstockwell wrote:
> > Is there a bug which explains why these changes are being made?
> 
> Unfortunately, no.

If there is a method to file a master bug as WebKit, please let me know.

[tkent, 2013-10-21 05:37:21]

On 2013/10/21 05:33:57, gyuyoung wrote:
> On 2013/10/21 05:30:37, tkent wrote:
> > On 2013/10/21 05:27:45, dstockwell wrote:
> > > Is there a bug which explains why these changes are being made?
> > 
> > Unfortunately, no.
> 
> If there is a method to file a master bug as WebKit, please let me know.

I made crbug.com/309516 .

[dstockwell, 2013-10-21 05:42:17]

> toAnimatableFoo was wrong. WebKit/Blink convention is that toFoo should accept
> null because it's a replacement of static_cast<>.

I see. This seems OK then. This will probably conflict with
https://codereview.chromium.org/27572003/

[gyuyoung-inactive, 2013-10-21 05:46:38]

On 2013/10/21 05:42:17, dstockwell wrote:
> > toAnimatableFoo was wrong. WebKit/Blink convention is that toFoo should
accept
> > null because it's a replacement of static_cast<>.
> 
> I see. This seems OK then. This will probably conflict with
> https://codereview.chromium.org/27572003/

Ok, I will update this cl after landing
https://codereview.chromium.org/27572003/ again.

[gyuyoung-inactive, 2013-10-21 09:33:55]

https://chromiumcodereview.appspot.com/29543005/diff/130001/Source/core/anima...
File Source/core/animation/AnimatableRepeatable.h (right):

https://chromiumcodereview.appspot.com/29543005/diff/130001/Source/core/anima...
Source/core/animation/AnimatableRepeatable.h:75:
DEFINE_TYPE_CASTS(AnimatableRepeatable, AnimatableValue, value,
(value->isRepeatable() || value->isStrokeDasharrayList()), (value.isRepeatable()
|| value.isStrokeDasharrayList()));
Unfortunately, current DEFINE_ANIMATABLE_VALUE_TYPE_CASTS can't support multiple
assertion conditions. So, in this case, I uses DEFINE_TYPE_CASTS directly. I
wonder how do you think about this usage.

[tkent, 2013-10-21 21:48:06]

lgtm

https://chromiumcodereview.appspot.com/29543005/diff/130001/Source/core/anima...
File Source/core/animation/AnimatableRepeatable.h (right):

https://chromiumcodereview.appspot.com/29543005/diff/130001/Source/core/anima...
Source/core/animation/AnimatableRepeatable.h:75:
DEFINE_TYPE_CASTS(AnimatableRepeatable, AnimatableValue, value,
(value->isRepeatable() || value->isStrokeDasharrayList()), (value.isRepeatable()
|| value.isStrokeDasharrayList()));
On 2013/10/21 09:33:55, gyuyoung wrote:
> Unfortunately, current DEFINE_ANIMATABLE_VALUE_TYPE_CASTS can't support
multiple
> assertion conditions. So, in this case, I uses DEFINE_TYPE_CASTS directly. I
> wonder how do you think about this usage.

Using generic DEFINE_TYPE_CASTS is reasonable.

[commit-bot: I haz the power, 2013-10-21 21:49:08]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/gyuyoung.kim@samsung.com/29543005/130001

[commit-bot: I haz the power, 2013-10-22 08:37:46]

Change committed as 160151