Replace execStateFrom*() functions with globalObject() overloads

• Component: Web Audio
• Status: RESOLVED FIXED

[Chris Dumez]

Introduce execStateFromWorkerOrWorletGlobalScope() to replace existing execStateFromWorkerGlobalScope() & execStateFromWorkletGlobalScope(). This is a first step to promote code sharing. Ideally, code would not have to differentiate workers from worklets as much as possible.

[Chris Dumez]

Created attachment 411765 [details]
Patch

[Darin Adler]

Comment on attachment 411765 [details]
Patch

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

Looks great, r=me assuming all tests pass.

> Source/WebCore/ChangeLog:10
> +        Introduce execStateFromWorkerOrWorletGlobalScope() to replace existing execStateFromWorkerGlobalScope()
> +        and execStateFromWorkletGlobalScope(). This is a first step to promote code sharing. Ideally, code
> +        would not have to differentiate workers from worklets as much as possible.

I don’t think we call this "exec state" any more, we call it "JavaScript global object". Is there some way to take advantage of that? Maybe all of these functions should get new names.

[Chris Dumez]

(In reply to Darin Adler from comment #2)
> Comment on attachment 411765 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=411765&action=review
> 
> Looks great, r=me assuming all tests pass.
> 
> > Source/WebCore/ChangeLog:10
> > +        Introduce execStateFromWorkerOrWorletGlobalScope() to replace existing execStateFromWorkerGlobalScope()
> > +        and execStateFromWorkletGlobalScope(). This is a first step to promote code sharing. Ideally, code
> > +        would not have to differentiate workers from worklets as much as possible.
> 
> I don’t think we call this "exec state" any more, we call it "JavaScript
> global object". Is there some way to take advantage of that? Maybe all of
> these functions should get new names.

How about jsGlobalObjectFrom*()?

[Sam Weinig]

Comment on attachment 411765 [details]
Patch

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

> Source/WebCore/inspector/agents/worker/WorkerAuditAgent.cpp:58
> +    JSC::JSGlobalObject* scriptState = execStateFromWorkerOrWorkletGlobalScope(m_workerGlobalScope);

If you are going to rename this, can you rename it to globalObjectFromWorkerOrWorkletGlobalScope(). We should try to remove the term ExecState from the source over time.

[Chris Dumez]

(In reply to Sam Weinig from comment #4)
> Comment on attachment 411765 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=411765&action=review
> 
> > Source/WebCore/inspector/agents/worker/WorkerAuditAgent.cpp:58
> > +    JSC::JSGlobalObject* scriptState = execStateFromWorkerOrWorkletGlobalScope(m_workerGlobalScope);
> 
> If you are going to rename this, can you rename it to
> globalObjectFromWorkerOrWorkletGlobalScope(). We should try to remove the
> term ExecState from the source over time.

Ok, will do.

[Chris Dumez]

Created attachment 411775 [details]
Patch

[Darin Adler]

Comment on attachment 411775 [details]
Patch

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

> Source/WebCore/bindings/js/ScriptState.h:57
> +JSC::JSGlobalObject* globalObjectFromNode(DOMWrapperWorld&, Node*);
> +WEBCORE_EXPORT JSC::JSGlobalObject* globalObjectFromPage(DOMWrapperWorld&, Page*);
> +JSC::JSGlobalObject* globalObjectFromWorkerOrWorkletGlobalScope(WorkerOrWorkletGlobalScope&);

Love this.

I might even suggest going further and go overload-crazy and just name the functions globalObject. After all, the functions get the global object "from" the arguments, and each of them does the right thing given the argument types and is not ambiguous.

[Chris Dumez]

(In reply to Darin Adler from comment #7)
> Comment on attachment 411775 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=411775&action=review
> 
> > Source/WebCore/bindings/js/ScriptState.h:57
> > +JSC::JSGlobalObject* globalObjectFromNode(DOMWrapperWorld&, Node*);
> > +WEBCORE_EXPORT JSC::JSGlobalObject* globalObjectFromPage(DOMWrapperWorld&, Page*);
> > +JSC::JSGlobalObject* globalObjectFromWorkerOrWorkletGlobalScope(WorkerOrWorkletGlobalScope&);
> 
> Love this.
> 
> I might even suggest going further and go overload-crazy and just name the
> functions globalObject. After all, the functions get the global object
> "from" the arguments, and each of them does the right thing given the
> argument types and is not ambiguous.

Sounds great. Any preference on the name then? I like globalObject() but I think it will conflict with some local variable names.

[Darin Adler]

(In reply to Chris Dumez from comment #8)
> Sounds great. Any preference on the name then? I like globalObject() but I
> think it will conflict with some local variable names.

Well, I usually don’t mind so much if something conflicts with local variable names, but if we want to side-step that it could be one of these:

    scriptGlobalObject
    currentGlobalObject
    owningGlobalObject
    lookUpGlobalObject
    findGlobalObject

I think the question is what we would be likely to say if we were talking about this. Typically when I need a name like this, I start talking to someone who explains what it is, and then I try to pick out words they use in the conversation.

[Sam Weinig]

(In reply to Chris Dumez from comment #8)
> (In reply to Darin Adler from comment #7)
> > Comment on attachment 411775 [details]
> > Patch
> > 
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=411775&action=review
> > 
> > > Source/WebCore/bindings/js/ScriptState.h:57
> > > +JSC::JSGlobalObject* globalObjectFromNode(DOMWrapperWorld&, Node*);
> > > +WEBCORE_EXPORT JSC::JSGlobalObject* globalObjectFromPage(DOMWrapperWorld&, Page*);
> > > +JSC::JSGlobalObject* globalObjectFromWorkerOrWorkletGlobalScope(WorkerOrWorkletGlobalScope&);
> > 
> > Love this.
> > 
> > I might even suggest going further and go overload-crazy and just name the
> > functions globalObject. After all, the functions get the global object
> > "from" the arguments, and each of them does the right thing given the
> > argument types and is not ambiguous.
> 
> Sounds great. Any preference on the name then? I like globalObject() but I
> think it will conflict with some local variable names.

I would try to make it just globalObject(), and change the locals if there is a problem.

[Chris Dumez]

Created attachment 411791 [details]
Patch

[Chris Dumez]

Created attachment 411792 [details]
Patch

[Chris Dumez]

Created attachment 411793 [details]
Patch

[Chris Dumez]

Created attachment 411794 [details]
Patch

[EWS]

Committed r268700: <https://trac.webkit.org/changeset/268700>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 411794 [details].

[Radar WebKit Bug Importer]

<rdar://problem/70462305>