Split out the JSScope from JSFunction so that we can easily have a JSScope for Program and Eval CallFrames.
Created attachment 237934 [details] Patch
Comment on attachment 237934 [details] Patch You need to update the cake lists, but otherwise yay! r=me
Created attachment 237963 [details] Added speculative fix for EWS build failures
Committed r173541: <http://trac.webkit.org/changeset/173541>
Probably best for JSCallee not to have a create function, since it doesn't make sense to create an object of type JSCallee.
(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.
> 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*);
(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.
Actually, I guess if we're only going to access scope, and not executable, it might be fine not to have subclasses.