On Jun 8, 2011, at 11:48 AM, Peter Kasting wrote:
On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak m...@apple.com 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.
On Thu, Jun 9, 2011 at 2:49 AM, Maciej Stachowiak m...@apple.com 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
On Thu, Jun 9, 2011 at 3:51 PM, Maciej Stachowiak m...@apple.com 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
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
On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak m...@apple.com 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
On Jun 8, 2011, at 11:48 AM, Peter Kasting wrote:
On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak m...@apple.com 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.
On Wed, Jun 8, 2011 at 11:51 AM, Darin Adler da...@apple.com wrote:
On Jun 8, 2011, at 11:48 AM, Peter Kasting wrote:
On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak m...@apple.com
wrote:
1) We definitely have consensus to fix the broken non-logically-const
accessors by making them
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:59 AM, Darin Adler da...@apple.com 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
On Fri, Jun 3, 2011 at 5:59 PM, Darin Adler da...@apple.com 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
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 takes const
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*), EditingBoundaryCrossingRule
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 Position p, bool
On Fri, Jun 3, 2011 at 5:27 PM, Darin Adler da...@apple.com 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
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 correct,
On Jun 1, 2011, at 8:11 PM, James Robinson wrote:
On Tue, May 31, 2011 at 12:08 PM, Geoffrey Garen gga...@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
On Tue, May 31, 2011 at 12:08 PM, Geoffrey Garen gga...@apple.com 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
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*
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 yong.li.web...@gmail.com:
I think we should add a rule like a const member function should
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
On Thu, Jun 2, 2011 at 1:02 PM, Geoffrey Garen gga...@apple.com 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
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
On Tue, May 31, 2011 at 11:31 PM, Maciej Stachowiak m...@apple.com 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
On Tue, May 31, 2011 at 11:31 PM, Maciej Stachowiak m...@apple.com 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
On Tue, May 31, 2011 at 12:08 PM, Geoffrey Garen gga...@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
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
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
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 side
On Mon, May 30, 2011 at 11:32 PM, Maciej Stachowiak m...@apple.com 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
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 can have side
On May 31, 2011, at 10:54 AM, Peter Kasting wrote:
On Mon, May 30, 2011 at 11:32 PM, Maciej Stachowiak m...@apple.com 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
On Tue, May 31, 2011 at 11:00 AM, Maciej Stachowiak m...@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
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.
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 reference by
Hi,
On Tue, May 31, 2011 at 4:37 PM, Maciej Stachowiak m...@apple.com 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
On May 31, 2011, at 5:55 PM, Brent Fulgham wrote:
Hi,
On Tue, May 31, 2011 at 4:37 PM, Maciej Stachowiak m...@apple.com 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
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
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 Mon, May 30, 2011 at 4:02 PM, Geoffrey Garen gga...@apple.com 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,
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
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 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 potential
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 potential callees to change their signatures recursively, and if
43 matches
Mail list logo
