Rename DOMPoint to WebKitPoint in C++ sides.

Rename DOMPoint to WebKitPoint in C++ sides.

The WebKitPoint interface implemented as DOMPoint in C++ sides.
Its name can conflict with a new implementation of DOMPoint.
So, we should rename DOMPoint to WebKitPoint in C++ sides.
We will have to remove it after a new implementation is shipped.

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

[zino, 2014-07-17 13:57:52]

Please take a look.

[haraken, 2014-07-17 14:39:34]

Would you elaborate on what's going to happen on DOMPoint and WebKitPoint (with
a link to some spec-side discussion)?

[zino, 2014-07-17 14:59:39]

On 2014/07/17 14:39:34, haraken wrote:
> Would you elaborate on what's going to happen on DOMPoint and WebKitPoint
(with
> a link to some spec-side discussion)?

Ah, Sorry.

I have a plan to implement a new DOMPoint (which is a part of geometry
interface).
I already send a intent to implement.
(https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/V_bJNtOg0oM)

And, WIP CL - You are already reviewer in the CL.
(https://codereview.chromium.org/399923002/)

I guess WebKitPoint is too old and it isn't aligned with the spec.
However, it has been shipped for a long time. so, we can't remove it easily.
(I think we need to send "intent to remove and deprecated" and measure
useCounter).

BTW, This CL is not web-facing change and so I think this is a trivial because
of changing only internal name.
(to prevent a conflict with new implementation of DOMPoint)

Thank you.

[haraken, 2014-07-17 15:09:32]

Thanks for the background.

> I guess WebKitPoint is too old and it isn't aligned with the spec.
> However, it has been shipped for a long time. so, we can't remove it easily.
> (I think we need to send "intent to remove and deprecated" and measure
> useCounter).

Yes, it would be nice to get useCounters to see if we can deprecate the
WebKitPoint.

> BTW, This CL is not web-facing change and so I think this is a trivial because
> of changing only internal name.
> (to prevent a conflict with new implementation of DOMPoint)

Agreed. This CL just changes internal names to make it possible to implement a
new DOMPoint in the code base.

LGTM, but Rik should confirm.

[abarth-chromium, 2014-07-17 18:02:31]

What's the differnce between WebKitPoint and DOMPoint?

[zino, 2014-07-18 00:41:49]

On 2014/07/17 18:02:31, abarth wrote:
> What's the differnce between WebKitPoint and DOMPoint?

I think WebKitPoint is the same with DOMPoint.
(Please refer to here: https://bugzilla.mozilla.org/show_bug.cgi?id=850805)
The WebKitPoint is currently exposed in Blink and it has only two attributes x,
y.

However, standard DOMPoint can have more attributes and more methods.
So, if we implement them on WebKitPoint, they can be exposed more than we
expected.

[abarth-chromium, 2014-07-18 03:04:48]

On 2014/07/18 at 00:41:49, jinho.bang wrote:
> On 2014/07/17 18:02:31, abarth wrote:
> > What's the differnce between WebKitPoint and DOMPoint?
> 
> I think WebKitPoint is the same with DOMPoint.
> (Please refer to here: https://bugzilla.mozilla.org/show_bug.cgi?id=850805)
> The WebKitPoint is currently exposed in Blink and it has only two attributes
x, y.
> 
> However, standard DOMPoint can have more attributes and more methods.
> So, if we implement them on WebKitPoint, they can be exposed more than we
expected.

That's fine.  It's better to extend WebKitPoint to match DOMPoint than to
introduce a new class.

[Rik, 2014-07-18 03:26:57]

On 2014/07/18 03:04:48, abarth wrote:
> That's fine.  It's better to extend WebKitPoint to match DOMPoint than to
> introduce a new class.

What do you mean by that? DOMPoint should be introduced as a new class.

LGTM

[abarth-chromium, 2014-07-18 04:04:02]

On 2014/07/18 at 03:26:57, cabanier wrote:
> On 2014/07/18 03:04:48, abarth wrote:
> > That's fine.  It's better to extend WebKitPoint to match DOMPoint than to
> > introduce a new class.
> 
> What do you mean by that? DOMPoint should be introduced as a new class.

Eventually we'll want to delete WebKitPoint.  In the meantime, it can just be an
alias for DOMPoint.

[zino, 2014-07-18 09:06:00]

On 2014/07/18 04:04:02, abarth wrote:
> Eventually we'll want to delete WebKitPoint.  In the meantime, it can just be
an
> alias for DOMPoint.

I have a question.
Can we have only one implementation per two IDL interfaces?

I tried..

[
  ImplementedAs=DOMPoint
] WebKitPoint {
  ...
};

[
  // SKIP: ImplementedAs=DOMPoint
] DOMPoint {
  ...
};

Then we can have only one implementation in c++ sides but it will be conflicted.

[zino, 2014-07-18 13:11:54]

FYI, I've just uploaded DOMPoint implementation (WIP CL).
https://codereview.chromium.org/404803002/

I think we should need renaming because the new DOMPoint is derived from
DOMPointReadOnly and WebKitPoint is depend on other APIs.

[abarth-chromium, 2014-07-18 18:00:44]

On 2014/07/18 at 09:06:00, jinho.bang wrote:
> On 2014/07/18 04:04:02, abarth wrote:
> > Eventually we'll want to delete WebKitPoint.  In the meantime, it can just
be an
> > alias for DOMPoint.
> 
> I have a question.
> Can we have only one implementation per two IDL interfaces?

Nope.

[zino, 2014-07-21 05:52:10]

Dear Adam,

Do you agree?
Would you mind if I commit this?

[abarth-chromium, 2014-07-21 06:23:25]

On 2014/07/21 at 05:52:10, jinho.bang wrote:
> Do you agree?
> Would you mind if I commit this?

It's fine.  We can merge these later.

[zino, 2014-07-21 13:53:48]

The CQ bit was checked by jinho.bang@samsung.com

[commit-bot: I haz the power, 2014-07-21 13:54:32]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/jinho.bang@samsung.com/404473004/1

[commit-bot: I haz the power, 2014-07-21 14:39:05]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  android_blink_compile_dbg on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/android_blink_compile_db...)
  android_chromium_gn_compile_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/android_chromium_gn_comp...)
  blink_presubmit on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/blink_presubmit/builds/1...)
  linux_blink_dbg on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/linux_blink_dbg/builds/1...)
  linux_chromium_gn_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/linux_chromium_gn_rel/bu...)
  mac_blink_compile_dbg on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/mac_blink_compile_dbg/bu...)
  win_blink_compile_dbg on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/win_blink_compile_dbg/bu...)
  linux_gpu on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/linux_gpu/builds/...)
  mac_gpu on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/mac_gpu/builds/31006)

[commit-bot: I haz the power, 2014-07-21 14:40:16]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-07-21 14:40:17]

Try jobs failed on following builders:
  mac_blink_compile_dbg on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/mac_blink_compile_dbg/bu...)
  mac_gpu on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/mac_gpu/builds/31018)

[zino, 2014-07-21 14:59:12]

The CQ bit was checked by jinho.bang@samsung.com

[commit-bot: I haz the power, 2014-07-21 14:59:46]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/jinho.bang@samsung.com/404473004/20001

[commit-bot: I haz the power, 2014-07-21 16:02:01]

Change committed as 178566