Bug 182901 - Add SVGPropertyTraits::fromString() to all the SVG animated types
Summary: Add SVGPropertyTraits::fromString() to all the SVG animated types
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Said Abou-Hallawa
URL:
Keywords: InRadar
Depends on:
Blocks: 168586
  Show dependency treegraph
 
Reported: 2018-02-16 20:59 PST by Said Abou-Hallawa
Modified: 2018-02-19 18:04 PST (History)
6 users (show)

See Also:


Attachments
Patch (70.68 KB, patch)
2018-02-16 21:31 PST, Said Abou-Hallawa
no flags Details | Formatted Diff | Diff
Patch (70.41 KB, patch)
2018-02-16 21:48 PST, Said Abou-Hallawa
no flags Details | Formatted Diff | Diff
Patch (70.65 KB, patch)
2018-02-19 16:48 PST, Said Abou-Hallawa
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Said Abou-Hallawa 2018-02-16 20:59:21 PST
This is a code refactoring, It is part of the patch of https://bugs.webkit.org/show_bug.cgi?id=168586. The final goal is to templatize the SVGAnimatedType class and to use SVGPropertyTraits methods inside the template functions.
Comment 1 Said Abou-Hallawa 2018-02-16 21:31:38 PST
Created attachment 334101 [details]
Patch
Comment 2 Said Abou-Hallawa 2018-02-16 21:48:50 PST
Created attachment 334102 [details]
Patch
Comment 3 Dean Jackson 2018-02-19 13:41:03 PST
Comment on attachment 334102 [details]
Patch

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

> Source/WebCore/svg/SVGPathByteStream.h:60
> +    SVGPathByteStream(const SVGPathByteStream& other)
> +        : m_data(other.m_data)
>      {
> -        return m_data == other.m_data;
>      }
>  
> -    bool operator!=(const SVGPathByteStream& other) const
> +    SVGPathByteStream(SVGPathByteStream&& other)
> +        : m_data(WTFMove(other.m_data))
>      {
> -        return !(*this == other);
>      }

I'm not sure if we tend to write these in the style:

SVGPBS(SVGPBS&& other)
{
  *this = WTFMove(other);
}

Since we have operator= below.

> Source/WebCore/svg/properties/SVGPropertyTraits.h:52
> +        return color.isValid() ? color : std::optional<Color>();

Why isn't this 

return color.isValid() ? color : std::nullopt; ?

Or, if it can't be a nullopt, why does it return an optional?

Same for the other parse() functions below.
Comment 4 Said Abou-Hallawa 2018-02-19 16:48:01 PST
Created attachment 334203 [details]
Patch
Comment 5 Said Abou-Hallawa 2018-02-19 16:55:45 PST
Comment on attachment 334102 [details]
Patch

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

>> Source/WebCore/svg/SVGPathByteStream.h:60
>>      }
> 
> I'm not sure if we tend to write these in the style:
> 
> SVGPBS(SVGPBS&& other)
> {
>   *this = WTFMove(other);
> }
> 
> Since we have operator= below.

I do not think there is a style guidelines here but I changed the copy and the move constructors to use the copy and the move assignment operators.

>> Source/WebCore/svg/properties/SVGPropertyTraits.h:52
>> +        return color.isValid() ? color : std::optional<Color>();
> 
> Why isn't this 
> 
> return color.isValid() ? color : std::nullopt; ?
> 
> Or, if it can't be a nullopt, why does it return an optional?
> 
> Same for the other parse() functions below.

It has to return an optional because parse() may fail. The ternary operator does not like std::nullopt because its type isn't compatible with Color. The only way to use std::nullopt is to break the return statement into an if-else statement or

if (!color.isValid())
    return std::nullopt;
return color;
Comment 6 WebKit Commit Bot 2018-02-19 18:03:02 PST
Comment on attachment 334203 [details]
Patch

Clearing flags on attachment: 334203

Committed r228721: <https://trac.webkit.org/changeset/228721>
Comment 7 WebKit Commit Bot 2018-02-19 18:03:04 PST
All reviewed patches have been landed.  Closing bug.
Comment 8 Radar WebKit Bug Importer 2018-02-19 18:04:37 PST
<rdar://problem/37693498>