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 <[email protected]>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 <[email protected]> > wrote: > > On Thu, Oct 25, 2012 at 3:48 AM, Andreas Kling <[email protected]> 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 > [email protected] > http://lists.webkit.org/mailman/listinfo/webkit-dev >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
