IDL: Support 'stringifier' keyword

IDL: Support 'stringifier' keyword

Usable in one of these forms:

  stringifier;
  stringifier DOMString ();
  stringifier DOMString name();
  stringifier attribute DOMString name;

All cause a toString() method to be defined on the interface automatically.
The first two are equivalent, and call CPPClass::toString() to retrieve the
string value. The latter two use CPPClass::name() to retrieve the string
value and also declare a regular attribute and operation, respectively.

Changed all simple "DOMString toString()" occurrences in IDL files to use
"stringifier" instead.

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

[Jens Widell, 2014-06-23 14:08:07]

Please take a look.

I've left some existing toString() methods in interfaces untouched:

- URLUtils and URLUtilsReadOnly, because they're supposed to be 'stringifier
attribute ...' and the attribute in question has non-standard extended
attributes that complicates things a bit.

- Location, where the 'toString' property is and probably should be
[NotEnumerable], but should be 'stringifier attribute ...' and the attribute in
question shouldn't be [NotEnumerable], and also various extended attributes both
on the toString() method and the attribute.

- DOMException, because Web IDL doesn't support stringifier as an exception
member, and thus this requires non-standard grammar in the parser if we want it.

https://codereview.chromium.org/345393004/diff/90001/Source/bindings/scripts/...
File Source/bindings/scripts/idl_definitions.py (right):

https://codereview.chromium.org/345393004/diff/90001/Source/bindings/scripts/...
Source/bindings/scripts/idl_definitions.py:609: """Return a synthesized
'toString' operation from the stringifier."""
I don't know if we think this is too much logic to put here in idl_definitions.
Synthesizing an IdlOperation like this was a convenient way to implement it.

[haraken, 2014-06-23 16:33:19]

https://codereview.chromium.org/345393004/diff/90001/Source/bindings/scripts/...
File Source/bindings/scripts/idl_definitions.py (right):

https://codereview.chromium.org/345393004/diff/90001/Source/bindings/scripts/...
Source/bindings/scripts/idl_definitions.py:609: """Return a synthesized
'toString' operation from the stringifier."""
On 2014/06/23 14:08:07, Jens Lindström wrote:
> I don't know if we think this is too much logic to put here in
idl_definitions.
> Synthesizing an IdlOperation like this was a convenient way to implement it.

Yeah, this looks like a bit too much logic in idl_defitions. We might want to
avoid writing "toString" or "ImplementedAs" here.

https://codereview.chromium.org/345393004/diff/90001/Source/core/dom/Range.idl
File Source/core/dom/Range.idl (right):

https://codereview.chromium.org/345393004/diff/90001/Source/core/dom/Range.id...
Source/core/dom/Range.idl:60: stringifier;

Not related to this CL, doesn't this have [NotEnumerable] ?

[Jens Widell, 2014-06-23 17:09:11]

https://codereview.chromium.org/345393004/diff/90001/Source/core/dom/Range.idl
File Source/core/dom/Range.idl (right):

https://codereview.chromium.org/345393004/diff/90001/Source/core/dom/Range.id...
Source/core/dom/Range.idl:60: stringifier;
On 2014/06/23 16:33:19, haraken wrote:
> 
> Not related to this CL, doesn't this have [NotEnumerable] ?

Doesn't in the spec (http://w3c.github.io/dom/#interface-range) at least. And
Web IDL doesn't support non-enumerable stringifiers at all.

But arv thinks they should be:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26179

[Jens Widell, 2014-06-24 08:00:29]

https://codereview.chromium.org/345393004/diff/90001/Source/bindings/scripts/...
File Source/bindings/scripts/idl_definitions.py (right):

https://codereview.chromium.org/345393004/diff/90001/Source/bindings/scripts/...
Source/bindings/scripts/idl_definitions.py:609: """Return a synthesized
'toString' operation from the stringifier."""
On 2014/06/23 16:33:18, haraken wrote:
> On 2014/06/23 14:08:07, Jens Lindström wrote:
> > I don't know if we think this is too much logic to put here in
> idl_definitions.
> > Synthesizing an IdlOperation like this was a convenient way to implement it.
> 
> Yeah, this looks like a bit too much logic in idl_defitions. We might want to
> avoid writing "toString" or "ImplementedAs" here.

Moved this code into interface_context() in v8_interface.py now. As a result,
the synthesized toString() method ends up last rather than where the stringifier
was declared in the interface, so there is now some superficial CG changes.

[haraken, 2014-06-24 08:28:36]

LGTM

https://codereview.chromium.org/345393004/diff/130001/Source/bindings/scripts...
File Source/bindings/scripts/idl_definitions.py (right):

https://codereview.chromium.org/345393004/diff/130001/Source/bindings/scripts...
Source/bindings/scripts/idl_definitions.py:316: elif self.stringifier.operation
and self.stringifier.operation.name:

Do we need the 'and self.stringifier.operation.name' check?

https://codereview.chromium.org/345393004/diff/130001/Source/bindings/scripts...
File Source/bindings/scripts/v8_interface.py (right):

https://codereview.chromium.org/345393004/diff/130001/Source/bindings/scripts...
Source/bindings/scripts/v8_interface.py:263:
method.extended_attributes.update(stringifier.extended_attributes)

method.extended_attributes = stringifier.extended_attributes

https://codereview.chromium.org/345393004/diff/130001/Source/bindings/scripts...
Source/bindings/scripts/v8_interface.py:264: if stringifier.attribute:

stringifier.attribute and stringifier.attribute.name ?

[Jens Widell, 2014-06-24 08:38:43]

https://codereview.chromium.org/345393004/diff/130001/Source/bindings/scripts...
File Source/bindings/scripts/idl_definitions.py (right):

https://codereview.chromium.org/345393004/diff/130001/Source/bindings/scripts...
Source/bindings/scripts/idl_definitions.py:316: elif self.stringifier.operation
and self.stringifier.operation.name:
On 2014/06/24 08:28:36, haraken wrote:
> 
> Do we need the 'and self.stringifier.operation.name' check?

Need that check somewhere because there will be an unnamed operation in the

  stringifier DOMString ();

case. But now that I think about it, it would probably be better to handle that
case in IdlStringifier.__init__(), since we now handle it both here and in the
block of code in interface_context().

https://codereview.chromium.org/345393004/diff/130001/Source/bindings/scripts...
File Source/bindings/scripts/v8_interface.py (right):

https://codereview.chromium.org/345393004/diff/130001/Source/bindings/scripts...
Source/bindings/scripts/v8_interface.py:263:
method.extended_attributes.update(stringifier.extended_attributes)
On 2014/06/24 08:28:36, haraken wrote:
> 
> method.extended_attributes = stringifier.extended_attributes

I'm modifying method.extended_attributes below, and with your alternative I
would then also be modifying stringifier.extended_attributes. That doesn't make
any difference in practice (now), but I'd argue it's better to copy the dict
items here than to use the same dict object.

https://codereview.chromium.org/345393004/diff/130001/Source/bindings/scripts...
Source/bindings/scripts/v8_interface.py:264: if stringifier.attribute:
On 2014/06/24 08:28:36, haraken wrote:
> 
> stringifier.attribute and stringifier.attribute.name ?

The attribute can't be unnamed. That would be

  stringifier attribute DOMString;

which is not supported by the grammar. (And if I move the handling of the
unnamed operation case away from here, the apparent asymmetry goes away.)

[haraken, 2014-06-24 08:40:49]

On 2014/06/24 08:38:43, Jens Lindström wrote:
>
https://codereview.chromium.org/345393004/diff/130001/Source/bindings/scripts...
> File Source/bindings/scripts/idl_definitions.py (right):
> 
>
https://codereview.chromium.org/345393004/diff/130001/Source/bindings/scripts...
> Source/bindings/scripts/idl_definitions.py:316: elif
self.stringifier.operation
> and self.stringifier.operation.name:
> On 2014/06/24 08:28:36, haraken wrote:
> > 
> > Do we need the 'and self.stringifier.operation.name' check?
> 
> Need that check somewhere because there will be an unnamed operation in the
> 
>   stringifier DOMString ();
> 
> case. But now that I think about it, it would probably be better to handle
that
> case in IdlStringifier.__init__(), since we now handle it both here and in the
> block of code in interface_context().
> 
>
https://codereview.chromium.org/345393004/diff/130001/Source/bindings/scripts...
> File Source/bindings/scripts/v8_interface.py (right):
> 
>
https://codereview.chromium.org/345393004/diff/130001/Source/bindings/scripts...
> Source/bindings/scripts/v8_interface.py:263:
> method.extended_attributes.update(stringifier.extended_attributes)
> On 2014/06/24 08:28:36, haraken wrote:
> > 
> > method.extended_attributes = stringifier.extended_attributes
> 
> I'm modifying method.extended_attributes below, and with your alternative I
> would then also be modifying stringifier.extended_attributes. That doesn't
make
> any difference in practice (now), but I'd argue it's better to copy the dict
> items here than to use the same dict object.
> 
>
https://codereview.chromium.org/345393004/diff/130001/Source/bindings/scripts...
> Source/bindings/scripts/v8_interface.py:264: if stringifier.attribute:
> On 2014/06/24 08:28:36, haraken wrote:
> > 
> > stringifier.attribute and stringifier.attribute.name ?
> 
> The attribute can't be unnamed. That would be
> 
>   stringifier attribute DOMString;
> 
> which is not supported by the grammar. (And if I move the handling of the
> unnamed operation case away from here, the apparent asymmetry goes away.)

Thanks, all of your comments make sense to me.

[Jens Widell, 2014-06-24 10:54:46]

The CQ bit was checked by jl@opera.com

[commit-bot: I haz the power, 2014-06-24 10:55:31]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/jl@opera.com/345393004/150001

[Jens Widell, 2014-06-24 10:55:34]

The CQ bit was checked by jl@opera.com

[commit-bot: I haz the power, 2014-06-24 10:55:56]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/jl@opera.com/345393004/150001

[commit-bot: I haz the power, 2014-06-24 12:06:47]

Change committed as 176833

[f(malita), 2014-06-24 14:42:08]

On 2014/06/24 12:06:47, I haz the power (commit-bot) wrote:
> Change committed as 176833

This broke the Linux GN build:
http://build.chromium.org/p/chromium.webkit/builders/Linux%20GN/builds/1918/s...

[Jens Widell, 2014-06-24 14:43:27]

On 2014/06/24 14:42:08, Florin Malita wrote:
> On 2014/06/24 12:06:47, I haz the power (commit-bot) wrote:
> > Change committed as 176833
> 
> This broke the Linux GN build:
>
http://build.chromium.org/p/chromium.webkit/builders/Linux%20GN/builds/1918/s...

Known. Fix in https://codereview.chromium.org/349413004/.