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

[Brendan Eich]

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.

/be
>
> Geoff
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev