Our strategy for this kind of problem, rather than re-engineering code to work
around inlining dependencies, is just to make a separate "{Class}Inlines.h",
where the inline functions are defined, and require any .cpp file that calls
those functions to #include "{Class}.h" and "{Class}Inlines.h".
Geoff
On Apr 30, 2012, at 9:54 AM, Andy Wingo wrote:
> On Thu 26 Apr 2012 11:59, Andy Wingo <[email protected]> writes:
>
>> As we discussed last week, it could be a good idea to inline
>> ScopeChainNode into scope objects, effectively giving scope objects a
>> pointer to the next object in the chain.
>
> Before I go too far down this thing, a note. This makes the scope chain
> link a part of JSScope, a derived JSObject. The scope chain is the part
> of the call frame that holds onto the JSGlobalObject and JSGlobalData,
> and the compiler needs to be able to inline exec->globalData() /
> exec->globalObject() in a whole pile of code, including JSObject.h
> itself.
>
> I am going to attempt to make JSObject.h not dereference the ExecState*
> data type. There are only a few cases in which it needs to do this, but
> changing those cases to accept a JSGlobalObject& ends up changing the
> prototype of JSObject::getOwnPropertySlot. I think I can manage this
> change, but it is a fair amount of work, and I wanted to get some
> feedback before getting too deep.
>
> Thoughts?
>
> Andy
>
> ps. This is unrelated to https://bugs.webkit.org/show_bug.cgi?id=85200.
> --
> http://wingolog.org/
> _______________________________________________
> squirrelfish-dev mailing list
> [email protected]
> http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
_______________________________________________
squirrelfish-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev