<div class="gmail_quote">On Wed, Jun 8, 2011 at 11:51 AM, Darin Adler <span dir="ltr"><<a href="mailto:darin@apple.com">darin@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Jun 8, 2011, at 11:48 AM, Peter Kasting wrote:<br>> On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak <<a href="mailto:mjs@apple.com">mjs@apple.com</a>> wrote:<br>
>> 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.<br>
><br>
> 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.<br>

<br>
</div>I thought you did it already locally. You mentioned that you decided for many member functions that the right thing was to remove const. I suggested you land those changes first, before making the other changes.<br>

<br>
Are we talking about the same thing? Maybe you think Maciej is asking for something he�s not.</blockquote><div><br></div><div>Maybe I got confused. �Some accessors cannot be const at all (IMO), like the ones that update layout before returning the desired value. �Other accessors, e.g. parentNode(), don't themselves do anything non-const and so they could theoretically be valid as const and non-const versions. �What I thought Maciej was saying was that we should remove "const" on all the existing accessors, in both categories, which sounded different than what you were saying (which I read as "remove const on the accessors in the first category").</div>
<div><br></div><div>I'm perfectly happy removing "const" from accessors in the first category. �I can post a change that does that before going any further.</div><div><br></div><div>PK</div></div>