Bug 136725 – Move JSScope out of JSFunction into separate JSCallee class

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Michael Saboff]

Split out the JSScope from JSFunction so that we can easily have a JSScope for Program and Eval CallFrames.

[Michael Saboff]

Created attachment 237934 [details]
Patch

[Oliver Hunt]

Comment on attachment 237934 [details]
Patch

You need to update the cake lists, but otherwise yay! r=me

[Michael Saboff]

Created attachment 237963 [details]
Added speculative fix for EWS build failures

[Michael Saboff]

Committed r173541: <http://trac.webkit.org/changeset/173541>

[Geoffrey Garen]

Probably best for JSCallee not to have a create function, since it doesn't make sense to create an object of type JSCallee.

[Michael Saboff]

(In reply to comment #5)
> Probably best for JSCallee not to have a create function, since it doesn't make sense to create an object of type JSCallee.

I thought we agreed that we'd create a JSCallee for program and eval frames and put that object in the JSCallee slot.

[Geoffrey Garen]

> I thought we agreed that we'd create a JSCallee for program and eval frames and put that object in the JSCallee slot.

Do you plan to use the JSCallee type for eval and program? I assumed you would create a subclass for each, like we have for JSFunction.

Side note: These functions probably belong in JSFunction, since they are for functions only:

 51    JS_EXPORT_PRIVATE String name(ExecState*);
 52    JS_EXPORT_PRIVATE String displayName(ExecState*);
 53    const String calculatedDisplayName(ExecState*);

[Michael Saboff]

(In reply to comment #7)
> > I thought we agreed that we'd create a JSCallee for program and eval frames and put that object in the JSCallee slot.
> 
> Do you plan to use the JSCallee type for eval and program? I assumed you would create a subclass for each, like we have for JSFunction.

We can create subclasses, but what would be in the subclass for program, eval (and global exec)?  If you want subclasses just to distinguish use I can do that, but I think it might be more confusing to have the subclasses.

> Side note: These functions probably belong in JSFunction, since they are for functions only:
> 
>  51    JS_EXPORT_PRIVATE String name(ExecState*);
>  52    JS_EXPORT_PRIVATE String displayName(ExecState*);
>  53    const String calculatedDisplayName(ExecState*);

I'll remove these.

[Geoffrey Garen]

Actually, I guess if we're only going to access scope, and not executable, it might be fine not to have subclasses.