[webkit-dev] Do we have a style preference about const member functions?

Maciej Stachowiak mjs at apple.com
Thu Jun 9 02:53:09 PDT 2011

On Jun 9, 2011, at 2:49 AM, Maciej Stachowiak wrote:

> On Jun 8, 2011, at 11:48 AM, Peter Kasting wrote:
>> On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>> 1) We definitely have consensus to fix the broken non-logically-const accessors by making them non-const; consensus on also adding const accessors is less clear.
>> There are a surprising number of places that actually do const traversals.  Simply making all these accessors non-const will require removing a lot of valid const usage from the existing code.  I'm really uncomfortable with that.
>> 2) We like to do things incrementally and fixing bad use of const before adding good use of const seems like this is a logical way to split the work and make it less of a megapatch.
>> Incremental fixes are absolutely the way to go.  Reviewing megapatches sucks and it's hard to catch subtle bugs like "you changed this function to be not const, but there's no reason to do that".
>> Perhaps a split that avoids removing existing, valid const usage would be to first change few (or no) function signatures, and simply modify caller code to be more consistent about type declarations. This would mean converting some callers from "Node*" to "const Node*" when they're doing true const traversals, and some the opposite direction when they're not.  The goal would be to make eventual API changes a no-op in terms of caller effect.  It'd be easy to make these sorts of patches arbitrarily small as well.
> How about posting a reasonable-sized patch that handles a few related, representative methods so we can evaluate.

Now having read the rest of the thread, I think you should start by posting what you and Darin agreed to.

 - Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110609/a03e8ff1/attachment.html>

More information about the webkit-dev mailing list