[webkit-dev] On returning mutable pointers from const methods

[Hajime Morrita]

We could have both const and non-const versions. For document(), we will
certainly need both.

I think these APIs can become less useful because the strict const-ness is
yet to be deployed widely. We can apply the rule for fresh classes line new
Web APIs since these rule worry little about older, less-const code. We'll
need certain level of compromise for existing code. This means we cannot
automate these check but it looks a reasonable starting point.

--
morrita


On Fri, Oct 26, 2012 at 12:53 PM, Elliott Sprehn <esprehn at chromium.org>wrote:

> This requires weird contortions in the DOM and Render tree and removes
> nice guarantees.
>
> For example Node.h has:
>
> TreeScope* treeScope() const;
> Document* document() const;
> Node* childNode(unsigned index) const;
>
> Returning a const Document* or Node* from childNode makes the DOM
> API's suddenly less useful, and marking them as non-const is
> confusing. These methods shouldn't be making mutations and the
> compiler should enforce that (or at least try to), and the const is also
> good
> documentation.
>
> On Thu, Oct 25, 2012 at 1:02 PM, Peter Kasting <pkasting at google.com>
> wrote:
> > On Thu, Oct 25, 2012 at 3:48 AM, Andreas Kling <kling at webkit.org> wrote:
> >>
> >> So, I propose that we allow only these two signature formats for raw
> >> pointers:
> >>
> >> - const Foo* foo() const;
> >> - Foo* foo();
> >
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121026/cfbf9a7a/attachment.html>