On Thu, Jun 9, 2011 at 3:51 PM, Maciej Stachowiak wrote:
> In principle, the return value could have been retrieved from a container
> that the immediate callee only has a const reference to. So then casting
> away const on the return value would be a hazard.
>
You're right; if the implementatio
On Jun 9, 2011, at 11:13 AM, Peter Kasting wrote:
> On Thu, Jun 9, 2011 at 2:49 AM, Maciej Stachowiak wrote:
> I'm not really convinced that casting away const from a return value is
> intrinsically safer than casting away const from "this".
>
> Allowing the caller to mutate the return value i
On Thu, Jun 9, 2011 at 2:49 AM, Maciej Stachowiak wrote:
>
> I'm not really convinced that casting away const from a return value is
> intrinsically safer than casting away const from "this".
>
Allowing the caller to mutate the return value is fine because the caller
had a non-const |this| to beg
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 wrote:
>> 1) We definitely have consensus to fix the broken non-logically-const
>> accessors by making them non-const; consensus o
On Jun 8, 2011, at 11:48 AM, Peter Kasting wrote:
> On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak 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
On Wed, Jun 8, 2011 at 11:59 AM, Darin Adler wrote:
> On Jun 8, 2011, at 11:56 AM, Peter Kasting wrote:
> > I'm perfectly happy removing "const" from accessors in the first
> category. I can post a change that does that before going any further.
>
> Yes, I believe that’s what both Maciej and I we
On Jun 8, 2011, at 11:56 AM, Peter Kasting wrote:
> 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
On Wed, Jun 8, 2011 at 11:51 AM, Darin Adler wrote:
> On Jun 8, 2011, at 11:48 AM, Peter Kasting wrote:
> > On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak
> wrote:
> >> 1) We definitely have consensus to fix the broken non-logically-const
> accessors by making them non-const; consensus on al
On Jun 8, 2011, at 11:48 AM, Peter Kasting wrote:
> On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak 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
On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak 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 trave
On Jun 7, 2011, at 4:22 PM, Darin Adler wrote:
> I think the “make some things non-const” part of this would be the first part
> to put up for review and land.
To expand on Darin's remark in two different ways:
1) We definitely have consensus to fix the broken non-logically-const accessors
by
I think the “make some things non-const” part of this would be the first part
to put up for review and land.
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Fri, Jun 3, 2011 at 5:59 PM, Darin Adler wrote:
> On Jun 3, 2011, at 5:46 PM, Peter Kasting wrote:
>
> > From the perspective of Node itself, I'm not sure why this would be a
> "big task". There shouldn't be any const accessors that return non-const
> pointers. Simply removing the "const" qual
On Jun 3, 2011, at 5:46 PM, Peter Kasting wrote:
> From the perspective of Node itself, I'm not sure why this would be a "big
> task". There shouldn't be any const accessors that return non-const pointers.
> Simply removing the "const" qualifier on all the above accessors would make
> things co
On Fri, Jun 3, 2011 at 5:27 PM, Darin Adler wrote:
> From a const Node* you can get:
>
>- a non-const pointer to a parent, sibling, or child
>- a non-const pointer to the document
>- a non-const pointer to the renderer
>- a non-const pointer to the style
>- a non-const pointer
On Jun 3, 2011, at 9:28 AM, Maciej Stachowiak wrote:
> On Jun 3, 2011, at 7:50 AM, Darin Adler wrote:
>
>> On Jun 2, 2011, at 1:32 AM, Ryosuke Niwa wrote:
>>
>>> All functions passed to enclosingNodeOfType in htmlediting.cpp are such
>>> clients:
>>>
>>> Node* enclosingNodeOfType(const Positio
On Jun 3, 2011, at 7:50 AM, Darin Adler wrote:
> On Jun 2, 2011, at 1:32 AM, Ryosuke Niwa wrote:
>
>> All functions passed to enclosingNodeOfType in htmlediting.cpp are such
>> clients:
>>
>> Node* enclosingNodeOfType(const Position& p, bool (*nodeIsOfType)(const
>> Node*), EditingBoundaryCro
On Jun 2, 2011, at 1:32 AM, Ryosuke Niwa wrote:
> All functions passed to enclosingNodeOfType in htmlediting.cpp are such
> clients:
>
> Node* enclosingNodeOfType(const Position& p, bool (*nodeIsOfType)(const
> Node*), EditingBoundaryCrossingRule rule)
>
> It takes a boolean function that take
On Thu, Jun 2, 2011 at 1:02 PM, Geoffrey Garen wrote:
> Perhaps we could at least encourage const-correctness for newly-written
> classes? By this I mean both adherence to the logical-constness rules you
> stated earlier as well as not adding non-const accessors and members unless
> needed -- oth
Responding to a few comments at once:
> 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 c
Similar thing: doc->frame()->document().
The solution should be defining both const and non-const members:
const Frame* frame() const { reutrn m_frame; }
Frame* frame() { return m_frame; }
2011/6/2 Yong Li :
> I think we should add a rule like "a const member function should
> never return non-c
I think we should add a rule like "a const member function should
never return non-const pointer/reference".
I have seen the problem in many places that you can get non-const
reference on a const object.
For example, InlineTextBox has
InlineTextBox* prevTextBox() const;
InlineTextBox* nextTextBo
On Thu, Jun 2, 2011 at 12:38 AM, Maciej Stachowiak wrote:
>
> 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 (o
On Tue, May 31, 2011 at 12:08 PM, Geoffrey Garen wrote:
>
> 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 meaning
On Jun 1, 2011, at 8:11 PM, James Robinson wrote:
> On Tue, May 31, 2011 at 12:08 PM, Geoffrey Garen 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 st
On Tue, May 31, 2011 at 12:08 PM, Geoffrey Garen 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 ref
On Tue, May 31, 2011 at 11:31 PM, Maciej Stachowiak wrote:
> [...] What do you believe is the proper const-correct way to write
> previousSibling() and related methods?
> A priori, I think the correct way is this:
>
> Node* previousSibling() { return m_previous; }
>
> I could also be convinced t
On Tue, May 31, 2011 at 11:31 PM, Maciej Stachowiak wrote:
> The following would be valid but would require us to cast away const all
> over the place and would therefore in my opinion be a net negative:
>
> const Node* previousSibling() const { return m_previous; }
>
> And what's in our code no
On May 31, 2011, at 10:00 PM, Brent Fulgham wrote:
>
> On May 31, 2011, at 8:44 PM, Maciej Stachowiak wrote:
>
>> For example, the compiler does not tell you that the following
>> implementation of Node::previousSibling() (currently in our code!) is
>> totally wrong from the "logical const" p
On May 31, 2011, at 8:44 PM, Maciej Stachowiak wrote:
> For example, the compiler does not tell you that the following implementation
> of Node::previousSibling() (currently in our code!) is totally wrong from the
> "logical const" perspective:
>
>Node* previousSibling() const { return m_p
On May 31, 2011, at 5:55 PM, Brent Fulgham wrote:
> Hi,
>
> On Tue, May 31, 2011 at 4:37 PM, Maciej Stachowiak wrote:
>> I agree that one useful distinction is whether a particular kind of object
>> is every manipulated via const pointers or references. If we never use const
>> references/point
Hi,
On Tue, May 31, 2011 at 4:37 PM, Maciej Stachowiak wrote:
> I agree that one useful distinction is whether a particular kind of object
> is every manipulated via const pointers or references. If we never use const
> references/pointers to a particular kind of object, then it is probably not
>
On May 31, 2011, at 12:08 PM, Geoffrey Garen 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 ref
> 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 a
On Tue, May 31, 2011 at 11:00 AM, Maciej Stachowiak 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 ref
On May 31, 2011, at 10:54 AM, Peter Kasting wrote:
> On Mon, May 30, 2011 at 11:32 PM, Maciej Stachowiak wrote:
> A linked list node or tree node could useful have const methods, which give
> only const pointers/references to other nodes. If there is a reason const
> references to DOM nodes or
>>> Even in a class that is used in a tree, I still think simple member
>>> variable accessor methods (that do not return tree neighbors) should be
>>> const.
>>
>> OK. Why?
>
> Because it indicates to me and the compiler, that the method doesn't have
> side effects.
A const member function
On Mon, May 30, 2011 at 11:32 PM, Maciej Stachowiak wrote:
> A linked list node or tree node could useful have const methods, which give
> only const pointers/references to other nodes. If there is a reason const
> references to DOM nodes or renew objects are not useful, it is not due to
> the ob
On May 31, 2011, at 10:47 AM, Geoffrey Garen wrote:
>> Even in a class that is used in a tree, I still think simple member variable
>> accessor methods (that do not return tree neighbors) should be const.
>
> OK. Why?
Because it indicates to me and the compiler, that the method doesn't have s
> Even in a class that is used in a tree, I still think simple member variable
> accessor methods (that do not return tree neighbors) should be const.
OK. Why?
Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailm
On May 30, 2011, at 4:19 PM, Geoffrey Garen wrote:
> Updated:
>
> Const member functions:
>
> Do use const member functions in classes that are independent data holders,
> to help distinguish between references that can modify the data and
> references that can't.
>
> Do not use const member
On May 30, 2011, at 4:19 PM, Geoffrey Garen wrote:
> Updated:
>
> Const member functions:
>
> Do use const member functions in classes that are independent data holders,
> to help distinguish between references that can modify the data and
> references that can't.
>
> Do not use const member
Updated:
Const member functions:
Do use const member functions in classes that are independent data holders, to
help distinguish between references that can modify the data and references
that can't.
Do not use const member functions in classes that participate in object graphs,
since the dis
On Mon, May 30, 2011 at 4:02 PM, Geoffrey Garen wrote:
>
> Do not use const member functions in *complex classes that do a lot more
> than hold one piece of data*
>
I'm not sure if the complexity of a class or holding piece of data are
useful criteria. Looking at DOM or render tree, it seems tha
OK, how about this style guideline:
Const member functions:
Do use const member functions in classes that are simple data holders, to help
distinguish between references that can modify the data and references that
can't.
Do not use const member functions in complex classes that do a lot more
On May 28, 2011, at 5:15 PM, Geoffrey Garen wrote:
> This came up in https://bugs.webkit.org/show_bug.cgi?id=59604.
>
> My personal preference is against const member functions because they force
> many error-prone code changes: introducing a const forces the transitive
> closure of all potenti
46 matches
Mail list logo