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

Reply via email to