Bug 217912 - Replace execStateFrom*() functions with globalObject() overloads
Summary: Replace execStateFrom*() functions with globalObject() overloads
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Audio (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords: InRadar
Depends on: 222228
Blocks: 217724 217058
  Show dependency treegraph
 
Reported: 2020-10-19 11:03 PDT by Chris Dumez
Modified: 2021-02-24 10:59 PST (History)
19 users (show)

See Also:


Attachments
Patch (12.17 KB, patch)
2020-10-19 11:05 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (14.96 KB, patch)
2020-10-19 12:15 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (16.16 KB, patch)
2020-10-19 13:46 PDT, Chris Dumez
ews-feeder: commit-queue-
Details | Formatted Diff | Diff
Patch (41.86 KB, patch)
2020-10-19 13:54 PDT, Chris Dumez
ews-feeder: commit-queue-
Details | Formatted Diff | Diff
Patch (41.88 KB, patch)
2020-10-19 13:58 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (41.88 KB, patch)
2020-10-19 14:08 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 2020-10-19 11:03:25 PDT
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.
Comment 1 Chris Dumez 2020-10-19 11:05:45 PDT
Created attachment 411765 [details]
Patch
Comment 2 Darin Adler 2020-10-19 11:10:25 PDT
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.
Comment 3 Chris Dumez 2020-10-19 11:11:34 PDT
(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*()?
Comment 4 Sam Weinig 2020-10-19 11:12:37 PDT
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.
Comment 5 Chris Dumez 2020-10-19 11:13:18 PDT
(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.
Comment 6 Chris Dumez 2020-10-19 12:15:50 PDT
Created attachment 411775 [details]
Patch
Comment 7 Darin Adler 2020-10-19 12:30:32 PDT
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.
Comment 8 Chris Dumez 2020-10-19 12:32:55 PDT
(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.
Comment 9 Darin Adler 2020-10-19 12:38:58 PDT
(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.
Comment 10 Sam Weinig 2020-10-19 13:11:00 PDT
(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.
Comment 11 Chris Dumez 2020-10-19 13:46:23 PDT
Created attachment 411791 [details]
Patch
Comment 12 Chris Dumez 2020-10-19 13:54:49 PDT
Created attachment 411792 [details]
Patch
Comment 13 Chris Dumez 2020-10-19 13:58:42 PDT
Created attachment 411793 [details]
Patch
Comment 14 Chris Dumez 2020-10-19 14:08:39 PDT
Created attachment 411794 [details]
Patch
Comment 15 EWS 2020-10-19 16:51:03 PDT
Committed r268700: <https://trac.webkit.org/changeset/268700>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 411794 [details].
Comment 16 Radar WebKit Bug Importer 2020-10-19 16:52:18 PDT
<rdar://problem/70462305>