Re: [webkit-dev] Do we have a style preference about const member functions?
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 functions in classes that participate in object graphs, since the distinction is weak. Do not use const member functions for DOM or render tree nodes. While I agree as to the DOM or render tree, I'm not sure this statement is right in general. 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 object graph participation itself, in my opinion. Regards, Maciej Geoff On May 30, 2011, at 4:08 PM, Ryosuke Niwa wrote: 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, it seems that we don't want to use const when an object constitutes (i.e. object's data members are essential in creating) a larger data structure such as a tree or a list. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
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/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
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 effects. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
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 to the object graph participation itself, in my opinion. Indeed. The rule of thumb I use is that a const member function should only return const-ref or pointer-to-const objects (whether as return values or outparams). This helps ensure that the method is logically const, not just physically const, by preventing callers from using const methods to gain handles they can use to modify supposedly-const objects. It so happens that objects in trees/graphs tend to have functions that return pointers to other objects much more frequently than do independent data holders. Thus Geoff's rule ends up approximating my rule, but is not equivalent. As to use of const in general, I would prefer to see more of it rather than less, _assuming it is used only for logical constness_. See Scott Meyers' Effective C++, item 3, for rationale. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
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 effects. It can modify any global state outside the object. It can also modify sub-objects inside the object, and return non-const references to sub-objects and related objects that might be used to produce side-effects at any time. It's exactly statements like this that make me think that const member functions are a bad idea -- people think they provide a guarantee, but they don't. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
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 DOM nodes or renew objects are not useful, it is not due to the object graph participation itself, in my opinion. Indeed. The rule of thumb I use is that a const member function should only return const-ref or pointer-to-const objects (whether as return values or outparams). This helps ensure that the method is logically const, not just physically const, by preventing callers from using const methods to gain handles they can use to modify supposedly-const objects. It so happens that objects in trees/graphs tend to have functions that return pointers to other objects much more frequently than do independent data holders. Thus Geoff's rule ends up approximating my rule, but is not equivalent. As to use of const in general, I would prefer to see more of it rather than less, _assuming it is used only for logical constness_. See Scott Meyers' Effective C++, item 3, for rationale. 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. This explains both why mutable data members are ok (they are meant for cache/memoization purposes, and do not alter observable state) and why const methods returning non-const pointers to other objects in a mutually referencing graph are not. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
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 or reference by which observable state of this object could be altered. Precisely! Because this is subtle, and can't be completely checked by a compiler, people can often get it wrong. Used correctly, though, const is a powerful tool for enforcing correct API usage, allowing optimizations, and informing readers of a class' contract and functionality. Reviewers should understand and consider these sorts of details. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
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.) Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Pages from the wiki vanished from google search results
Hi there. Since a couple of days ago (when?), our trac/wiki is not appearing as relevant on google search results anymore. I guess google blacklisted the site because of some sort of spam or a redirect against the rules. Does anyone know if something changed recently? Does someone has a google webmaster tools account to check? A few examples: http://www.google.com/search?hl=enq=webkit+team+%22Here+is+the+key+for+each%22 http://www.google.com/search?hl=enq=Qt+Port+of+WebKit+%22List+of+all+QtWebKit+wiki+pages%22 (here only pages mirroring our wiki appear on the search results) Thanks, - Ademar -- Ademar de Souza Reis Jr. ademar.r...@openbossa.org Nokia Institute of Technology ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKitGTK+ Lucid PPA now available
Hello fellow WebKittens, Recently many non-WebKitGTK+ developers have been kind enough to debug failures that only show up on WebKitGTK+. Since WebKitGTK+ typically tracks bleeding-edge GNOME, compiling can be a daunting task for those not up on the latest GNOME releases. In particular, some of you are stuck using Lucid. For those people, I've backported all WebKitGTK+ requirements to Lucid and published them in my PPA. Please see http://trac.webkit.org/wiki/BuildingGtk for details. Note: Both Fedora 15 and Ubuntu 11.04 (Natty Narwhal) contain the required dependencies. If you are not tied to a particular Linux release I recommend simply upgrading your system rather than using my PPA. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Pages from the wiki vanished from google search results
Someone could check: https://www.google.com/webmasters I no longer have access (but I could go through the process of getting access if needed). -eric On Tue, May 31, 2011 at 1:37 PM, Ademar Reis ademar.r...@openbossa.orgwrote: Hi there. Since a couple of days ago (when?), our trac/wiki is not appearing as relevant on google search results anymore. I guess google blacklisted the site because of some sort of spam or a redirect against the rules. Does anyone know if something changed recently? Does someone has a google webmaster tools account to check? A few examples: http://www.google.com/search?hl=enq=webkit+team+%22Here+is+the+key+for+each%22 http://www.google.com/search?hl=enq=Qt+Port+of+WebKit+%22List+of+all+QtWebKit+wiki+pages%22 (here only pages mirroring our wiki appear on the search results) Thanks, - Ademar -- Ademar de Souza Reis Jr. ademar.r...@openbossa.org Nokia Institute of Technology ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
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 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 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 useful to maintain const-correctness discipline for that class. If we wanted to make the DOM or render tree thoroughly const-correct, the key question would be what client code would access via const pointers or references. For container classes, it is almost certain that some client will wish to vend or consume const references, even if the very first client doesn't. There's probably other classes where it's less clear-cut. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
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 probably not useful to maintain const-correctness discipline for that class. I don't agree with this. I see no harm in maintaining const correctness on objects, even if they are not currently manipulated through const references/pointers. They provide clear, self-documenting evidence that the object design intends that certain methods do not visibly alter the object. I fail to see how abandoning const correctness can do anything but cause us to start missing bugs that we would otherwise have found via compiler errors. -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
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
references/pointers to a particular kind of object, then it is probably not
useful to maintain const-correctness discipline for that class.
I don't agree with this. I see no harm in maintaining const
correctness on objects, even if they are not currently manipulated
through const references/pointers. They provide clear,
self-documenting evidence that the object design intends that certain
methods do not visibly alter the object.
I fail to see how abandoning const correctness can do anything but
cause us to start missing bugs that we would otherwise have found via
compiler errors.
It's hard for me to evaluate this in the abstract. In general I like the
compiler telling me as much as possible. But there's both false positive and
false negative problems with const-correctness, and a maintenance burden
besides just fixing the compiler errors.
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_previous; }
The correct way to do const-correctness here would require more verbosity:
const Node* previousSibling() const { return m_previous; }
Node* previousSibling() { return m_previous; }
And the first variant would be dead code if we don't ever actually use const
node pointers.
Given your views on const-correctness discipline, what do you think is the
right way to handle this situation? Note that this pattern comes up for many
core DOM methods and many render tree methods.
Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
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_previous; }
The correct way to do const-correctness here would require more verbosity:
const Node* previousSibling() const { return m_previous; }
Node* previousSibling() { return m_previous; }
And the first variant would be dead code if we don't ever actually use const
node pointers.
Given your views on const-correctness discipline, what do you think is the
right way to handle this situation? Note that this pattern comes up for many
core DOM methods and many render tree methods.
One possible (though ugly) way of allowing the compiler to do some of this work
for you is to declare the m_previous member as a const pointer, and then
manipulate it only in specific routines using the const_cast operator to
allow it to mutate. But this is probably a case of the cure being worse than
the disease.
If we had logic that iterated over the node siblings in read-only fashion, we
would ideally do so through a const iterator. In addition to documenting that
we don't intend to mutate the object, it would provide potentially useful
information that compilers could use to make aliasing decisions and so forth.
Perhaps we never iterate over DOM nodes without intending to mutate them; if
so, I would agree that there is no benefit to maintaining the const variation.
However I do not think (as the Node example might imply) that the fact that the
compiler cannot identify ALL categories of const error means that we are better
off washing our hands of const correctness.
In fact, due to the viral nature of const-ness changes, leaving them in (and
continuing to maintain them) is a good long term approach since the first time
you want to work with a const Node object you will have to resurrect const
variations of methods across the object hierarchy.
-Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
