Bug 157465 - [Bindings] Simplify [RequiresExistingAtomicString] IDL extended attribute handling
Summary: [Bindings] Simplify [RequiresExistingAtomicString] IDL extended attribute han...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Bindings (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-08 13:25 PDT by Chris Dumez
Modified: 2016-05-08 14:56 PDT (History)
3 users (show)

See Also:


Attachments
Patch (16.44 KB, patch)
2016-05-08 13:39 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Dumez 2016-05-08 13:25:43 PDT
Simplify [RequiresExistingAtomicString] IDL extended attribute handling in the bindings generator.
Comment 1 Chris Dumez 2016-05-08 13:39:37 PDT
Created attachment 278370 [details]
Patch
Comment 2 Darin Adler 2016-05-08 13:46:49 PDT
Comment on attachment 278370 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=278370&action=review

> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:4382
> +        return ("AtomicString($value.toString(state)->toExistingAtomicString(state))", 1) if $signature->extendedAttributes->{"RequiresExistingAtomicString"};

The parentheses here after "return" are not normal perl coding style. I like it better without.

It’s irritating that we have to construct AtomicString rather than just passing the result of toExistingAtomicString. Does it compile without the explicit AtomicString?
Comment 3 Chris Dumez 2016-05-08 13:51:53 PDT
Comment on attachment 278370 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=278370&action=review

>> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:4382
>> +        return ("AtomicString($value.toString(state)->toExistingAtomicString(state))", 1) if $signature->extendedAttributes->{"RequiresExistingAtomicString"};
> 
> The parentheses here after "return" are not normal perl coding style. I like it better without.
> 
> It’s irritating that we have to construct AtomicString rather than just passing the result of toExistingAtomicString. Does it compile without the explicit AtomicString?

1. We use these parentheses in all return statements in this function. Do you want be to drop them all?
I am not Perl expert but I personally like the parentheses here as it makes it clear we're returning a tuple.

2. Yes, I have tried without the AtomicString() but it did not build. The compiler complains about it being ambiguous because there are 2 overloads in TreeScope.h:
    Element* getElementById(const AtomicString&) const;
    WEBCORE_EXPORT Element* getElementById(const String&) const;
Comment 4 Darin Adler 2016-05-08 14:39:25 PDT
Comment on attachment 278370 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=278370&action=review

>>> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:4382
>>> +        return ("AtomicString($value.toString(state)->toExistingAtomicString(state))", 1) if $signature->extendedAttributes->{"RequiresExistingAtomicString"};
>> 
>> The parentheses here after "return" are not normal perl coding style. I like it better without.
>> 
>> It’s irritating that we have to construct AtomicString rather than just passing the result of toExistingAtomicString. Does it compile without the explicit AtomicString?
> 
> 1. We use these parentheses in all return statements in this function. Do you want be to drop them all?
> I am not Perl expert but I personally like the parentheses here as it makes it clear we're returning a tuple.
> 
> 2. Yes, I have tried without the AtomicString() but it did not build. The compiler complains about it being ambiguous because there are 2 overloads in TreeScope.h:
>     Element* getElementById(const AtomicString&) const;
>     WEBCORE_EXPORT Element* getElementById(const String&) const;

Oops, need the parentheses. Forgot this was a tuple!

I really don’t get why toExistingAtomicString returns RefPtr<AtomicStringImpl> instead of AtomicString, but this code is all right with me.
Comment 5 Chris Dumez 2016-05-08 14:56:14 PDT
Comment on attachment 278370 [details]
Patch

Clearing flags on attachment: 278370

Committed r200562: <http://trac.webkit.org/changeset/200562>
Comment 6 Chris Dumez 2016-05-08 14:56:19 PDT
All reviewed patches have been landed.  Closing bug.