Remove DOM prefix from several IDL interfaces

Remove DOM prefix from several IDL interfaces

Remove DOM prefix from several IDL interfaces and use [ImplementedAs] extended
attribute instead of [InterfaceName] for those.

Also stop using [InterfaceName] in bindings tests.

[InterfaceName] is deprecated and we should progressively stop using it.

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

[haraken, 2013-05-13 13:53:27]

LGTM

https://codereview.chromium.org/14882009/diff/1/Source/bindings/scripts/CodeG...
File Source/bindings/scripts/CodeGeneratorV8.pm (right):

https://codereview.chromium.org/14882009/diff/1/Source/bindings/scripts/CodeG...
Source/bindings/scripts/CodeGeneratorV8.pm:2391: my $multiLine = ($functionCall
=~ tr/\n//) > 1;
Actually I don't want to mess up the code generator for this kind of things... I
think it's OK to generate {} for one-line if clause (as long as it doesn't make
the style checker angry).

[do-not-use, 2013-05-13 13:55:16]

On 2013/05/13 13:53:27, haraken wrote:
> LGTM
> 
>
https://codereview.chromium.org/14882009/diff/1/Source/bindings/scripts/CodeG...
> File Source/bindings/scripts/CodeGeneratorV8.pm (right):
> 
>
https://codereview.chromium.org/14882009/diff/1/Source/bindings/scripts/CodeG...
> Source/bindings/scripts/CodeGeneratorV8.pm:2391: my $multiLine =
($functionCall
> =~ tr/\n//) > 1;
> Actually I don't want to mess up the code generator for this kind of things...
I
> think it's OK to generate {} for one-line if clause (as long as it doesn't
make
> the style checker angry).

It makes the style checker unhappy, which is why I fixed it. So what should I
do?

[haraken, 2013-05-13 14:05:44]

ok, then let's keep your patch as is :)

[do-not-use, 2013-05-13 14:11:06]

On 2013/05/13 14:05:44, haraken wrote:
> ok, then let's keep your patch as is :)

Sorry, broke clean build :/ I'll investigate and reupload.

[arv (Not doing code reviews), 2013-05-13 14:47:07]

LGTM

[do-not-use, 2013-05-13 21:15:56]

Could someone please review the changes to:
Source/core/dom/DOMExceptions.in
Source/core/scripts/make_dom_exceptions.py
Source/core/scripts/name_macros.py

I fixed the build but I am not familiar with those scripts.

[abarth-chromium, 2013-05-13 22:33:42]

I'm not sure the change to the "in" file is exactly what we want to do.  Can we
do the exception part in a separate CL so that we can consider it properly?

[Chris Dumez, 2013-05-14 06:21:26]

On 2013/05/13 22:33:42, abarth wrote:
> I'm not sure the change to the "in" file is exactly what we want to do.  Can
we
> do the exception part in a separate CL so that we can consider it properly?

Yes, good idea. I'll remove it from this CL.

[do-not-use, 2013-05-14 08:48:53]

On 2013/05/14 06:21:26, dchris wrote:
> On 2013/05/13 22:33:42, abarth wrote:
> > I'm not sure the change to the "in" file is exactly what we want to do.  Can
> we
> > do the exception part in a separate CL so that we can consider it properly?
> 
> Yes, good idea. I'll remove it from this CL.

Ok, I have removed the DOMCoreException changes from this CL, as proposed. Is is
OK to land now?

[haraken, 2013-05-14 12:57:58]

LGTM.

[commit-bot: I haz the power, 2013-05-14 13:20:33]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ch.dumez@sisa.samsung.com/14882009/19001

[commit-bot: I haz the power, 2013-05-14 18:26:58]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ch.dumez@sisa.samsung.com/14882009/19001

[commit-bot: I haz the power, 2013-05-14 20:35:15]

Change committed as 150351