On Nov 5, 2012, at 4:15 PM, Brendan Eich <[email protected]> wrote:
> Geoffrey Garen wrote: >>> The proposed design requires adding a FooInlines.h include to source files >>> that use that function, when any function moves into FooInlines.h. This can >>> happen any time a function is made inline or when a short inline function >>> gets longer. >> >> You convinced me; I hadn't considered this burden. >> >> Le me amend: >> >>> (2) Adopt the convention that any class using "*Inlines.h" defines all >>> inline functions defined out-of-line in "*Inlines.h" >> >> To >> >> (2) Adopt the convention that nothing goes into "*Inlines.h" by default, and >> functions are added on demand as we discover functions that cause compile >> failures or long compile times. > > Hi Geoff, sorry to stick my nose in it but Mozilla uses WebKit code (YARR, > <3) so we care. The strong reason we've found beyond compile failures and > long compile times (or really, this is the underlying cause of either compile > failures or, alternatively, long compile times): inline method > implementations are not appropriate to put in interface definitions. > > In other words, Foo.h declaring class Foo can focus on interface over > implementation, even with a few short inline methods defined within the class > or right after it -- but larger inlines may be required for performance, and > their bodies can easily depend on headers not properly part of > Foo.h-as-interface, which should therefore not "bootleg" along via nested > #includes. Whereas FooInlines.h can nest its implementation dependencies > freely. > > Implementation vs. interface distinctions can be fuzzy, but we've found it > helpful to use this as a razor when shaving header files with inlines, before > compile errors or compile time problems bite. I think that the total time spent fixing dependencies due to inline methods being in the main header is going to be less than the total time spent having to search through multiple headers when doing normal work. As I've pointed out in past messages in this thread, we have classes where the best documentation of a method is the method's body - hence having the body inline is a big win for productivity. This may have more to due with how JSC is laid out. I think the last time I encountered a need to put a method body outside of the main header was over a month ago, if not more. -F > > /be >> >> Geoff >> >> _______________________________________________ >> webkit-dev mailing list >> [email protected] >> http://lists.webkit.org/mailman/listinfo/webkit-dev > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
