IDL compiler: anonymous indexed property getters

IDL compiler: anonymous indexed property getters

This starts special operations.
I've kept this simple, but I've made it generic, as we know
we'll also have indexed property setters, named property getters, etc.

For now I'm putting the tests in a separate file,
since these are interface-wide features, so I don't need to worry
about interface-wide extended attributes changing things.
Once I've implemented these, I'll merge them into the existing
TestInterfacePython tests to reduce the number of test results.

BUG=239771
R=haraken
NOTRY=true

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

[Nils Barth (inactive), 2014-01-27 06:29:48]

https://codereview.chromium.org/148083004/diff/1/Source/bindings/tests/idls/T...
File Source/bindings/tests/idls/TestSpecialOperations.idl (right):

https://codereview.chromium.org/148083004/diff/1/Source/bindings/tests/idls/T...
Source/bindings/tests/idls/TestSpecialOperations.idl:32:
[ImplementedAs=anonymousIndexedGetter] getter DOMString (unsigned long index);
Currently we *require* [ImplementedAs=...]
for anonymous special operations.

Could we use a default name, to simplify the IDL files?
E.g., anonymousIndexedGetter, or more precisely
anonymousIndexedPropertyGetter ?

[haraken, 2014-01-27 06:35:32]

https://codereview.chromium.org/148083004/diff/1/Source/bindings/scripts/unst...
File Source/bindings/scripts/unstable/v8_interface.py (right):

https://codereview.chromium.org/148083004/diff/1/Source/bindings/scripts/unst...
Source/bindings/scripts/unstable/v8_interface.py:480: getter = next(

This looks a bit complicated. Can we avoid using Python's generator?

https://codereview.chromium.org/148083004/diff/1/Source/bindings/scripts/unst...
Source/bindings/scripts/unstable/v8_interface.py:495: 'name':
extended_attributes['ImplementedAs'],

Why do we need to support [ImplementedAs] for "anonymous" indexed properties?

https://codereview.chromium.org/148083004/diff/1/Source/bindings/scripts/unst...
Source/bindings/scripts/unstable/v8_interface.py:500: def
getter_is_null_expression(idl_type):

Is this method only for getters?

https://codereview.chromium.org/148083004/diff/1/Source/bindings/scripts/unst...
Source/bindings/scripts/unstable/v8_interface.py:503: return None

How can we judge nullability for non-DOMString values?

https://codereview.chromium.org/148083004/diff/1/Source/bindings/templates/in...
File Source/bindings/templates/interface.cpp (right):

https://codereview.chromium.org/148083004/diff/1/Source/bindings/templates/in...
Source/bindings/templates/interface.cpp:106:
ASSERT(V8DOMWrapper::maybeDOMWrapper(info.Holder()));

You can remove this. It's guaranteed that info.Holder() is a DOM wrapper.

[Nils Barth (inactive), 2014-01-27 06:59:35]

https://codereview.chromium.org/148083004/diff/1/Source/bindings/scripts/unst...
File Source/bindings/scripts/unstable/v8_interface.py (right):

https://codereview.chromium.org/148083004/diff/1/Source/bindings/scripts/unst...
Source/bindings/scripts/unstable/v8_interface.py:480: getter = next(
On 2014/01/27 06:35:32, haraken wrote:
> This looks a bit complicated. Can we avoid using Python's generator?

Admittedly this looks a bit weird, but this is the most idiomatic way in
Python to get the first matching element of a list, basically because
generator expressions/list comprehensions are the idiomatic way to
*filter* a list:
http://stackoverflow.com/questions/9542738/python-find-in-list

The actual syntax is pretty simple:
try:
    foo = next(x for x in l if f(x))
except StopIteration:
    return None

The alternative:
for x in l:
    if f(x):
        foo = x
        break
else:
    return None
...is rather longer, and buries the assignment (the point of the statement!)
2 levels deep.

I used this last week, but the condition was simple, so it didn't
look so bad.

The actual complexity here is the condition statement,
because the parser doesn't select the indexed getter for us,
so we have to search for it.

I could put this obnoxious complexity in the parser,
once Perl is gone.

In Perl the search has special function, GetSpecialAccessorFunctionForType,
which is even longer and more complicated;
I think it's clearer to explicitly inline the test.

https://codereview.chromium.org/148083004/diff/1/Source/bindings/scripts/unst...
Source/bindings/scripts/unstable/v8_interface.py:495: 'name':
extended_attributes['ImplementedAs'],
On 2014/01/27 06:35:32, haraken wrote:
> Why do we need to support [ImplementedAs] for "anonymous" indexed properties?

See other comment:
anonymous means there's no name in the *IDL*,
but we need a name for the function in the Blink C++.

I'd prefer to remove this and default to a standard name,
like anonymousIndexedGetter (which is used in several IDLs).

https://codereview.chromium.org/148083004/diff/1/Source/bindings/scripts/unst...
Source/bindings/scripts/unstable/v8_interface.py:500: def
getter_is_null_expression(idl_type):
On 2014/01/27 06:35:32, haraken wrote:
> Is this method only for getters?

Yes; I've thus made it explicit.

https://codereview.chromium.org/148083004/diff/1/Source/bindings/scripts/unst...
Source/bindings/scripts/unstable/v8_interface.py:503: return None
On 2014/01/27 06:35:32, haraken wrote:
> How can we judge nullability for non-DOMString values?

See GenerateIsNullExpression
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

For interface types it's just !element, while for union types we need to recurse
on the elements.

I'll do this in followups, per type.

https://codereview.chromium.org/148083004/diff/1/Source/bindings/templates/in...
File Source/bindings/templates/interface.cpp (right):

https://codereview.chromium.org/148083004/diff/1/Source/bindings/templates/in...
Source/bindings/templates/interface.cpp:106:
ASSERT(V8DOMWrapper::maybeDOMWrapper(info.Holder()));
On 2014/01/27 06:35:32, haraken wrote:
> You can remove this. It's guaranteed that info.Holder() is a DOM wrapper.

Got it, posted CL:
Remove unnecessary maybeDOMWrapper from indexed/named property getters
https://codereview.chromium.org/138003013/

[haraken, 2014-01-27 07:04:39]

LGTM

https://codereview.chromium.org/148083004/diff/1/Source/bindings/scripts/unst...
File Source/bindings/scripts/unstable/v8_interface.py (right):

https://codereview.chromium.org/148083004/diff/1/Source/bindings/scripts/unst...
Source/bindings/scripts/unstable/v8_interface.py:480: getter = next(
On 2014/01/27 06:59:35, Nils Barth wrote:
> On 2014/01/27 06:35:32, haraken wrote:
> > This looks a bit complicated. Can we avoid using Python's generator?
> 
> Admittedly this looks a bit weird, but this is the most idiomatic way in
> Python to get the first matching element of a list, basically because
> generator expressions/list comprehensions are the idiomatic way to
> *filter* a list:
> http://stackoverflow.com/questions/9542738/python-find-in-list
> 
> The actual syntax is pretty simple:
> try:
>     foo = next(x for x in l if f(x))
> except StopIteration:
>     return None
> 
> The alternative:
> for x in l:
>     if f(x):
>         foo = x
>         break
> else:
>     return None
> ...is rather longer, and buries the assignment (the point of the statement!)
> 2 levels deep.
> 
> I used this last week, but the condition was simple, so it didn't
> look so bad.
> 
> The actual complexity here is the condition statement,
> because the parser doesn't select the indexed getter for us,
> so we have to search for it.
> 
> I could put this obnoxious complexity in the parser,
> once Perl is gone.
> 
> In Perl the search has special function, GetSpecialAccessorFunctionForType,
> which is even longer and more complicated;
> I think it's clearer to explicitly inline the test.

Understood, thanks for the clarification.

https://codereview.chromium.org/148083004/diff/1/Source/bindings/scripts/unst...
Source/bindings/scripts/unstable/v8_interface.py:495: 'name':
extended_attributes['ImplementedAs'],
On 2014/01/27 06:59:35, Nils Barth wrote:
> On 2014/01/27 06:35:32, haraken wrote:
> > Why do we need to support [ImplementedAs] for "anonymous" indexed
properties?
> 
> See other comment:
> anonymous means there's no name in the *IDL*,
> but we need a name for the function in the Blink C++.
> 
> I'd prefer to remove this and default to a standard name,
> like anonymousIndexedGetter (which is used in several IDLs).

Sounds better.

[Nils Barth (inactive), 2014-01-27 07:24:37]

Thanks!
Will followup with making anonymous operations really anonymous.

https://codereview.chromium.org/148083004/diff/1/Source/bindings/scripts/unst...
File Source/bindings/scripts/unstable/v8_interface.py (right):

https://codereview.chromium.org/148083004/diff/1/Source/bindings/scripts/unst...
Source/bindings/scripts/unstable/v8_interface.py:495: 'name':
extended_attributes['ImplementedAs'],
On 2014/01/27 07:04:40, haraken wrote:
> Sounds better.

Ok, I'll do this in a followup, as it touches real IDLs.

[commit-bot: I haz the power, 2014-01-28 00:44:53]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/nbarth@chromium.org/148083004/160001

[commit-bot: I haz the power, 2014-01-28 00:45:42]

Change committed as 165894