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 <wingo@igalia.com> 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 squirrelfish-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev