On Nov 2, 2012, at 5:48 PM, Mark Lam <mark....@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 buy the intent here and agree that JavaScriptCore has too much stuff in headers. But I don't think that this rule - any inline method over one line should be in a separate file - is going to be a good idea in the long term. For example, I would find it much more difficult to reason about DFG::AbstractValue if I had to be looking at two different files to do it. Same for DFG::Node. Probably others as well. The general challenge here is that many of the methods have semantics that are best deduced by not only reading their names but also looking at their contents. So, for most of the inline methods with which I am familiar, I'd prefer if they stayed where they are now. -F > > 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. > > Regards, > Mark > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
