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 shape of the class i.e. let's me see the architecture / 
> design, not just the implementation.
>    - having lots of inline functions bodies inside the class definition 
> bloats the class significantly and makes it harder to see the shape. (again, 
> a mental clutter issue).  Of course, if you have editor tools that can hide 
> the function bodies, this is not an issue.

Inline functions that are kept inside vs. outside class definitions is a 
separate issue from the in the same header file vs. in another header file.

I agree that class definitions are often significantly easier to read if all 
non-trivial function definitions are put outside the class. But requiring that 
all such function definitions be put into a separate file seems unduly awkward 
and heavy to me.

Maciej stated the reasons we have created such files in the past; the intent 
was not to put all inline functions in them. I would not want to create the 
many new files this new convention would require.

> By 1 liners, I mean something like:
> 
>     bool isFinished { return m_isFinished; }
> 
> … but now am realizing that this is not allowed by the webkit coding style, 
> which instead requires:
> 
>     bool isFinished
>     {
>         return m_isFinished;
>     } 

The WebKit coding style document might formally require that as currently 
written, but I think it’s a mistake and not consistent with the style we 
actually use in WebKit coding.

> I would propose updating the webkit coding style to allowing braces on the 
> same line for the case of 1 line inline functions

We should. It’s already part of WebKit coding style, even though it seems not 
yet part of the formal WebKit coding style document.

-- Darin
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to