[webkit-dev] …Inlines.h vs …InlineMethods.h

[Maciej Stachowiak]

On Nov 3, 2012, at 1:48 AM, Mark Lam <mark.lam at apple.com> wrote:

> FYI, some time in the near future (maybe this weekend), I plan to do some work to break inline methods in JavaScriptCore out of header files into their own inline header files.
> 
> Naming-wise, the existing JSC code has a few inline headers named …Inlines.h and more named …InlinedMethods.h.  On the WebCore side, the few that exists there are named …InlineMethods.h.  I have a preference for the …Inlines.h convention because it is shorter and concisely communicates the intent.  I plan to rename all these inline headers to be …Inlines.h for consistency.  Does anyone object to my renaming the inline headers?
> 
> Also, a lot of the existing inlined methods are 1 liners.  I plan to leave these in the original header file.  Here's the convention I'm going to adopt:
> 
> 1. If the inline method is a 1 liner, then leave it in the original header file.
> 2. If it takes more than 1 line, then move it into a corresponding inline header file.
> 
> I will only be breaking out the inline methods (per the above convention) in the JSC sources.  Apart from renaming the few WebCore inline headers, I won't be looking into WebCore's placement of inline methods for now.  
> 
> If anyone has an opinion on this, please let me know asap.  Thanks.

What is the intended benefit of more thoroughly splitting out inline methods? The two reasons I know to do it are:

(a) In some cases, it is required to avoid a circular dependency in header includes (where two classes have inline member functions that each depend on the other class).
(b) If inline methods require pulling in additional includes, but not all files including the main header need their definitions, it can speed up compile times.

The main downside is that you now have to keep track of whether you need the second header when you use a class, and if you forget, you may not see the failure until late in the build process.

It does not seem to me like a cutoff of 1 line vs more than 1 line is in very good alignment with reasons (a) and (b) to split inline member functions into a separate header. It also seems like it would create friction when changing inline methods, since taking it over or under the one-line cutoff would now require you to move it to a different file.

So I'd like to understand why we want to do this.

No objections on the rename though, Inlines.h is both more concise and more accurate than InlineMethods.h.

Regards,
Maciej