On Nov 5, 2012, at 8:47 AM, Geoffrey Garen gga...@apple.com wrote:
(2) Adopt the convention that any class using *Inlines.h defines all inline
functions defined out-of-line in *Inlines.h
This is a proposal I don’t agree with.
Making a firm rule here here means that every larger inline
Just so I understand, you're recommending we move functions like
Document::guardDeref()
http://trac.webkit.org/browser/trunk/Source/WebCore/dom/Document.h#L240
out of the class declaration, but leave them in the header file (e.g.,
in Document.h).
Correct.
And, if we decided to add
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.
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
On Nov 5, 2012, at 4:15 PM, Brendan Eich bren...@mozilla.org 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
Filip Pizlo wrote:
On Nov 5, 2012, at 4:15 PM, Brendan Eichbren...@mozilla.org wrote:
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
These rules generally look great. One suggestion:
On Nov 5, 2012, at 8:47 AM, Geoffrey Garen wrote:
(5) Adopt the convention that any function that is not as trivial as int x()
{ return m_x; } moves out of the class declaration.
How about we simplify this slightly to:
(5) Adopt the
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
(5) Adopt the convention that any function that is not as trivial as int
x() { return m_x; } moves out of the class declaration.
How about we simplify this slightly to:
(5) Adopt the convention that any function that is nontrivial should be moved
out of the class declaration.
We can
On Nov 5, 2012, at 9:27 PM, Geoffrey Garen gga...@apple.com wrote:
(5) Adopt the convention that any function that is not as trivial as int
x() { return m_x; } moves out of the class declaration.
How about we simplify this slightly to:
(5) Adopt the convention that any function that is
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
On Nov 3, 2012, at 10:09 AM, Mark Lam mark@apple.com wrote:
On Nov 3, 2012, at 2:11 AM, Maciej Stachowiak m...@apple.com wrote:
On Nov 3, 2012, at 1:48 AM, Mark Lam mark@apple.com wrote:
1. If the inline method is a 1 liner, then leave it in the original header
file.
2. If it
On Nov 3, 2012, at 10:09 AM, Mark Lam mark@apple.com wrote:
1. to keep class definitions more compact
- so you can see more of the entire class (not that this is always
possible anyway).
- being able to see the entire class (when possible) can yield useful
information about the
My understanding was that *Inlines/*InlineMethods were more about
limiting includes in the main header. Maybe that's just a happy side
effect. :)
I also prefer the *Inlines naming. :)
On Fri, Nov 2, 2012 at 5:48 PM, Mark Lam mark@apple.com wrote:
FYI, some time in the near future (maybe
On Fri, 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
15 matches
Mail list logo
