Bug 110159 - Web Inspector: take large strings out of CodeGeneratorInspector.py
Summary: Web Inspector: take large strings out of CodeGeneratorInspector.py
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated) (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-18 15:10 PST by Peter Rybin
Modified: 2013-02-21 04:39 PST (History)
9 users (show)

See Also:


Attachments
Patch (65.80 KB, patch)
2013-02-18 15:24 PST, Peter Rybin
no flags Details | Formatted Diff | Diff
Patch (65.80 KB, patch)
2013-02-19 14:28 PST, Peter Rybin
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Rybin 2013-02-18 15:10:48 PST
CodeGeneratorInspector.py largely contains multiline string literals.
Those should be taken away into a separate file to keep code and string resources better separated.
Comment 1 Peter Rybin 2013-02-18 15:24:12 PST
Created attachment 188951 [details]
Patch
Comment 2 Yury Semikhatsky 2013-02-19 01:55:00 PST
Comment on attachment 188951 [details]
Patch

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

> Source/WebCore/inspector/CodeGeneratorInspector.py:40
> +import CodeGeneratorInspectorStrings

Maybe CodeGeneratorInspectorTemplates?
Comment 3 Ilya Tikhonovsky 2013-02-19 02:09:20 PST
View in context: https://bugs.webkit.org/attachment.cgi?id=188951&action=review

What do you think about further splitting of this file. I'd expect to see one template file per one result file.

> Source/WebCore/inspector/CodeGeneratorInspectorStrings.py:701
> +#endif  // !ASSERT_DISABLED

Wrong comment here and in many other places like that.

> Source/WebCore/inspector/CodeGeneratorInspectorStrings.py:922
> +class_binding_builder_part_1 = (
> +"""        AllFieldsSet = %s
> +    };
> +
> +    template<int STATE>
> +    class Builder {
> +    private:
> +        RefPtr<InspectorObject> m_result;
> +
> +        template<int STEP> Builder<STATE | STEP>& castState()
> +        {
> +            return *reinterpret_cast<Builder<STATE | STEP>*>(this);
> +        }
> +
> +        Builder(PassRefPtr</*%s*/InspectorObject> ptr)
> +        {
> +            COMPILE_ASSERT(STATE == NoFieldsSet, builder_created_in_non_init_state);
> +            m_result = ptr;
> +        }
> +        friend class %s;
> +    public:
> +""")

I think that it would be more declarative and less error prone if you convert it to a function with named argument instead of a string.
Comment 4 Peter Rybin 2013-02-19 13:26:20 PST
> > Source/WebCore/inspector/CodeGeneratorInspector.py:40
> > +import CodeGeneratorInspectorStrings
> Maybe CodeGeneratorInspectorTemplates?

Please write how positive you are about this change, because I'm 50/50.

The reason why I chose "strings" is because I meant this file as plain storage for multiline strings. I don't care whether they are templates or what.

Multiline string is the only thing you cannot take with you into type-safe language if you ever want to.
Comment 5 Peter Rybin 2013-02-19 13:45:31 PST
> What do you think about further splitting of this file. I'd expect to see one template file per one result file.

That would bring more strange files into repository, but I don't see a clear benefit from this. You are not going to get a real general-purpose template engine anyway. Current code structure is very traceable. For example, all generated scripts declare the path to the generator file. 

> > Source/WebCore/inspector/CodeGeneratorInspectorStrings.py:701
> > +#endif  // !ASSERT_DISABLED
> Wrong comment here and in many other places like that.

Thanks.

> > Source/WebCore/inspector/CodeGeneratorInspectorStrings.py:922
> > +class_binding_builder_part_1 = (
> > +"""        AllFieldsSet = %s
> > +    };
> > +
> > +    template<int STATE>
> > +    class Builder {
> > +    private:
> > +        RefPtr<InspectorObject> m_result;
> > +
> > +        template<int STEP> Builder<STATE | STEP>& castState()
> > +        {
> > +            return *reinterpret_cast<Builder<STATE | STEP>*>(this);
> > +        }
> > +
> > +        Builder(PassRefPtr</*%s*/InspectorObject> ptr)
> > +        {
> > +            COMPILE_ASSERT(STATE == NoFieldsSet, builder_created_in_non_init_state);
> > +            m_result = ptr;
> > +        }
> > +        friend class %s;
> > +    public:
> > +""")
> 
> I think that it would be more declarative and less error prone if you convert it to a function with named argument instead of a string.

Unfortunately that's not what I planned to do. I see at as a collection of multiline string resources, no code or any other mark-up. If I ever were to switch script to type-safe language, I would need multiline strings separate. In this form as I suggest, I would be able to write a really simple RegExp-based parser to easily read this strings. This is basically a pseudo-python similar to like JSON is a pseuod-JavaScript.
Comment 6 Peter Rybin 2013-02-19 14:28:50 PST
Created attachment 189164 [details]
Patch
Comment 7 Yury Semikhatsky 2013-02-20 02:03:28 PST
(In reply to comment #4)
> > > Source/WebCore/inspector/CodeGeneratorInspector.py:40
> > > +import CodeGeneratorInspectorStrings
> > Maybe CodeGeneratorInspectorTemplates?
> 
> Please write how positive you are about this change, because I'm 50/50.
> 
> The reason why I chose "strings" is because I meant this file as plain storage for multiline strings. I don't care whether they are templates or what.
> 
> Multiline string is the only thing you cannot take with you into type-safe language if you ever want to.

Ok, that makes sense.
Comment 8 WebKit Review Bot 2013-02-21 04:39:31 PST
Comment on attachment 189164 [details]
Patch

Clearing flags on attachment: 189164

Committed r143586: <http://trac.webkit.org/changeset/143586>
Comment 9 WebKit Review Bot 2013-02-21 04:39:34 PST
All reviewed patches have been landed.  Closing bug.