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

[Maciej Stachowiak]

On Jun 1, 2011, at 8:11 PM, James Robinson wrote:

> On Tue, May 31, 2011 at 12:08 PM, Geoffrey Garen <ggaren at apple.com> wrote:
>> I agree that const should be used for "logical constness". The rule should not be merely "doesn't alter any data members of this object" but rather "does not alter observable state of this object or vend any type of pointer or reference by which observable state of this object could be altered".
>> 
>> Precisely!
> 
> I like this explanation too. 
> 
> I'm trying to think of a simple way to explain / test whether something falls into the category of logical constness, since it can be ambiguous.
> 
> It occurred to me that a simple, though imperfect, test is just, "Is this function called by an owner of a const pointer / reference?" After all, a const member function is meaningless if nobody points to the class through a const pointer  / reference. For classes like DOM and render tree nodes, which have no meaningful const-pointer-owning clients, the answer is always no. For other classes, the answer is yes, but only if someone has found a meaningful use for a const pointer or reference to the class.
> 
> So, perhaps the real style question we should answer is when to use const pointers / references, since the answer to when to use const member functions will follow from it.
> 
> What are some good examples of existing code that meaningfully uses a const pointer or reference? (Something other than, say, the obligatory const& in a copy constructor.)
> 
> I personally find that in a number of render tree functions declared to take a const RenderObject* that the const-ness is a useful hint that the function will not be manipulating the object in unexpected ways.  Examples:
> http://codesearch.google.com/codesearch?hl=en&vert=chromium&lr=&q=%22const+RenderObject%22+file%3AWebCore&sbtn=Search (click "Next" at the bottom to see more results).
> 
> My understanding is that these functions could not take a const RenderObject* parameter if RenderObject did not supply a set of const simple accessors and utility functions.  We could convert RenderObject over to have no const member functions and convert all of these utility functions to take RenderObject* parameters instead, but I think that would lose some of the intent of the code.
> 
> I'm curious if there was a specific patch or piece of code that lead you to send this email out - perhaps we make a better decision about whether to change our approach with more concrete examples of problems the current situation has caused or is causing.

Looks to me like these fulfill the requirement of "do we ever use const pointers to these objects". So the next step is to fix up const member functions that inappropriately return non-const pointers to objects in the same tree (or that can otherwise get a back pointer). Make the functions non-const, then add const variants returning a const pointer if needed.

I'm curious if there are any clients for const pointers to DOM nodes.

Regards,
Maciej


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