Bug 217912

Created attachment 411765 [details] Patch

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.

(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 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.

(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.

Created attachment 411775 [details] Patch

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.

(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.

(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.

(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.

Created attachment 411791 [details] Patch

Created attachment 411792 [details] Patch

Created attachment 411793 [details] Patch

Created attachment 411794 [details] Patch

Committed r268700: <https://trac.webkit.org/changeset/268700> All reviewed patches have been landed. Closing bug and clearing flags on attachment 411794 [details].

<rdar://problem/70462305>