[webkit-dev] webkit-dev Digest, Vol 73, Issue 2
Anna Kim
ynanna.kim at gmail.com
Thu Jun 2 14:52:43 PDT 2011
Thanks.
On Jun 2, 2011 11:00 PM, <webkit-dev-request at lists.webkit.org> wrote:
>
> Send webkit-dev mailing list submissions to
> webkit-dev at lists.webkit.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> or, via email, send a message with subject or body 'help' to
> webkit-dev-request at lists.webkit.org
>
> You can reach the person managing the list at
> webkit-dev-owner at lists.webkit.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of webkit-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Issue Analysis:48290 [HTML Canvas
> globalCompositeOperation] (Darin Adler)
> 2. Re: Issue Analysis:48290 [HTML Canvas
> globalCompositeOperation] (Mustafizur Rahaman)
> 3. Re: Issue Analysis:48290 [HTML Canvas
> globalCompositeOperation] (Darin Adler)
> 4. New page for viewing test failures on build.webkit.org
> (Adam Roben)
> 5. Cross-platform fonts for Layout Tests (Eric Seidel)
> 6. Re: Do we have a style preference about const member
> functions? (Peter Kasting)
> 7. Re: Pages from the wiki vanished from google search results
> (Robert Hogan)
> 8. Re: New page for viewing test failures on build.webkit.org
> (Adam Barth)
> 9. Re: Pages from the wiki vanished from google search results
> (Ademar Reis)
> 10. Re: Do we have a style preference about const member
> functions? (Brent Fulgham)
> 11. Different Versions of WebkitSupportLibrary.zip (Brian Stuart)
> 12. Re: Do we have a style preference about const member
> functions? (James Robinson)
> 13. Re: Do we have a style preference about const member
> functions? (Maciej Stachowiak)
> 14. Re: Do we have a style preference about const member
> functions? (Ryosuke Niwa)
> 15. Re: Cross-platform fonts for Layout Tests (Hao Zheng)
> 16. Re: Do we have a style preference about const member
> functions? (Ryosuke Niwa)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 01 Jun 2011 09:21:09 -0700
> From: Darin Adler <darin at apple.com>
> To: Karthik <sarap.karthik at gmail.com>
> Cc: webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] Issue Analysis:48290 [HTML Canvas
> globalCompositeOperation]
> Message-ID: <73B9726E-9D07-4252-8893-906E21F25E4B at apple.com>
> Content-Type: text/plain; charset=windows-1252
>
> On May 31, 2011, at 11:49 PM, Karthik wrote:
>
> > However, the following comment was mentioned in GraphicsType.h (" //
Note: These constants exactly match the NSCompositeOperator constants of //
AppKit on Mac OS X Tiger. If these ever change, we'll need to change the //
Mac OS X Tiger platform code to map one to the other. "). So I am little
unclear what is the purpose of this CompositeHighLight.
>
> We can remove that comment. It?s obsolete.
>
> I believe the ?highlight? compositing mode used to be supported in canvas
by WebKit on Mac, but hasn?t been for some time. There?s probably no harm in
removing it now.
>
> The fact that the string is ?not valid? in the specification isn?t what
makes it OK to remove. Please remember that the canvas implementation in
WebKit was the first and predates the specification by at least a year. But
it?s almost certainly OK to remove this compositing mode because it hasn?t
been implemented for quite a while.
>
> There?s still a slim chance that there is some content out there relying
on ?highlight? being a synonym for ?source-over?, but it?s not likely.
>
> One side comment: I think the mapping from strings to the various graphics
enums really belongs in the canvas code, not in the platform directory.
>
> -- Darin
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 1 Jun 2011 22:44:20 +0530
> From: Mustafizur Rahaman <mustaf.here at gmail.com>
> To: Darin Adler <darin at apple.com>
> Cc: webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] Issue Analysis:48290 [HTML Canvas
> globalCompositeOperation]
> Message-ID: <BANLkTi=J1gBxf+uuue+TW6Amv4zN_TWeEA at mail.gmail.com>
> Content-Type: text/plain; charset="windows-1252"
>
> Hi Darin,
>
> Thanks for your detailed explanation. Initially we decided to remove the
> string as well the enum to fix this issue. But Karthik's patch (we have
> already submitted the patch in
> https://bugs.webkit.org/show_bug.cgi?id=48290) caused a Chromium build
> issue & then we found that this enum is used in
> lot of other places. So, we were a little apprehensive about the side
effect
> of this fix.
>
> Therefore, we submitted another patch where we are returning from the
canvas
> code itself if the compositing mode is "highlight". We are still waiting
for
> the review comments.
>
> Similar issue (https://bugs.webkit.org/show_bug.cgi?id=48289 ) we have
also
> seen for "darker"/CompositePlusDarker (not a valid compositing mode any
> more). Can we also remove this as well?
>
> Thanks,
> Rahaman
>
> On Wed, Jun 1, 2011 at 9:51 PM, Darin Adler <darin at apple.com> wrote:
>
> > On May 31, 2011, at 11:49 PM, Karthik wrote:
> >
> > > However, the following comment was mentioned in GraphicsType.h ("
//
> > Note: These constants exactly match the NSCompositeOperator constants of
//
> > AppKit on Mac OS X Tiger. If these ever change, we'll need to change the
//
> > Mac OS X Tiger platform code to map one to the other. "). So I am little
> > unclear what is the purpose of this CompositeHighLight.
> >
> > We can remove that comment. It?s obsolete.
> >
> > I believe the ?highlight? compositing mode used to be supported in
canvas
> > by WebKit on Mac, but hasn?t been for some time. There?s probably no
harm in
> > removing it now.
> >
> > The fact that the string is ?not valid? in the specification isn?t what
> > makes it OK to remove. Please remember that the canvas implementation in
> > WebKit was the first and predates the specification by at least a year.
But
> > it?s almost certainly OK to remove this compositing mode because it
hasn?t
> > been implemented for quite a while.
> >
> > There?s still a slim chance that there is some content out there relying
on
> > ?highlight? being a synonym for ?source-over?, but it?s not likely.
> >
> > One side comment: I think the mapping from strings to the various
graphics
> > enums really belongs in the canvas code, not in the platform directory.
> >
> > -- Darin
> >
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
http://lists.webkit.org/pipermail/webkit-dev/attachments/20110601/86e812e9/attachment-0001.html
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 01 Jun 2011 10:19:50 -0700
> From: Darin Adler <darin at apple.com>
> To: Mustafizur Rahaman <mustaf.here at gmail.com>
> Cc: webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] Issue Analysis:48290 [HTML Canvas
> globalCompositeOperation]
> Message-ID: <EB93C273-0C72-4D61-9988-D34499897FD2 at apple.com>
> Content-Type: text/plain; charset="windows-1252"
>
> On Jun 1, 2011, at 10:14 AM, Mustafizur Rahaman wrote:
>
> > Therefore, we submitted another patch where we are returning from the
canvas code itself if the compositing mode is "highlight".
>
> That?s not a good idea. We should keep looking into the real fix; that
kind of hack is unneeded here.
>
> > Similar issue (https://bugs.webkit.org/show_bug.cgi?id=48289 ) we have
also seen for "darker"/CompositePlusDarker (not a valid compositing mode any
more). Can we also remove this as well?
>
> That?s different. That mode is implemented, so we?d have to be sure it
wasn?t used. We can?t remove it just because it?s not in the specification
without investigating what content depends on it.
>
> -- Darin
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
http://lists.webkit.org/pipermail/webkit-dev/attachments/20110601/fb6bed1a/attachment-0001.html
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 01 Jun 2011 15:22:25 -0400
> From: Adam Roben <aroben at apple.com>
> To: WebKit Development <webkit-dev at lists.webkit.org>
> Subject: [webkit-dev] New page for viewing test failures on
> build.webkit.org
> Message-ID: <3EF00935-A83E-4F51-B9F4-1AE7B63339CD at apple.com>
> Content-Type: text/plain; CHARSET=US-ASCII; format=flowed; delsp=yes
>
> Hi all-
>
> Before I go on vacation for 2.5 weeks, I wanted to let you know about
> a new page I've been working on on build.webkit.org. You can see it
> here:
>
> http://build.webkit.org/TestFailures/
>
> The idea of the page is to provide a single place to go to find out
> what tests are failing on the bots and when they started failing. It
> also tries to make it easy to file bugs about the failures.
>
> It is pretty ugly, and has some glaring bugs (search Bugzilla for
> "TestFailures"). But I've found it useful already. I hope you will, too!
>
> Please file bugs and feature requests in the Tools / Tests component
> of Bugzilla, include the word "TestFailures" in the bug, and CC me.
> The code lives in Tools/BuildSlaveSupport/build.webkit.org-config/
> public_html/TestFailures.
>
> Let me know what you think!
>
> -Adam
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 1 Jun 2011 12:30:04 -0700
> From: Eric Seidel <eric at webkit.org>
> To: WebKit Development <webkit-dev at lists.webkit.org>
> Subject: [webkit-dev] Cross-platform fonts for Layout Tests
> Message-ID: <BANLkTik5Ku0Bm87Ruz8ZPzZd_9q=8ntsHw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I know that Ahem is safe to use across multiple platforms (the font
metrics
> will be the same). Do we know if there are any other fonts for which this
> is true?
>
> I'd like to make the style-bot yell at people when they use pixel tests
with
> non-safe fonts. Right now that list would only include ahem.
>
> -eric
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
http://lists.webkit.org/pipermail/webkit-dev/attachments/20110601/fb75b783/attachment-0001.html
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 1 Jun 2011 13:20:28 -0700
> From: Peter Kasting <pkasting at chromium.org>
> To: Maciej Stachowiak <mjs at apple.com>
> Cc: WebKit-Dev Development <webkit-dev at lists.webkit.org>
> Subject: Re: [webkit-dev] Do we have a style preference about const
> member functions?
> Message-ID: <BANLkTim2mEB7WE9=pBDR3EMPXt9s8p+HXQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tue, May 31, 2011 at 11:31 PM, Maciej Stachowiak <mjs at 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 our code now violates the intent of const, and so to me at
> > least is clearly a bug:
> >
> > Node* previousSibling() const { return m_previous; }
> >
>
> I agree that these are both bad.
>
> Well one big problem right now (just from scanning the core DOM classes)
is
> > that we have a lot of clearly broken use of const. We could (a) leave it
> > as-is, (b) remove the incorrect use of const, or (c) deploy proper
> > const-correctness. it seems like you are against (b), but I cannot tell
if
> > you advocate (a) or (c).
> >
>
> Misusing const is IMO worse than not using const. I would be in favor of
> removing cases like the last one you cite above, as well as working to
> remove const_casts, at least where they indicate problems.
>
> It would be nice to make things more properly const-correct, and make
> callers use const accessors when possible (e.g. use the const form of tree
> iteration when walking a tree merely to read data and not write it), so I
> don't think we should forbid good use of const, but it's also
time-consuming
> to retrofit.
>
> 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 -- otherwise it's easy to just err on the side of never using const
> anywhere.
>
> I also think we should not discourage people from using "const" on
> variables. I've gotten review comments in the past that have asked me to
> remove const qualifiers on locals, as well as sometimes on arguments and
> members, and I think this is a mistake. "We aren't const-correct
elsewhere
> in WebCore" is not a good reason to forbid const.
>
> PK
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
http://lists.webkit.org/pipermail/webkit-dev/attachments/20110601/1f2bda88/attachment-0001.html
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 1 Jun 2011 21:27:17 +0100
> From: Robert Hogan <lists at roberthogan.net>
> To: webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] Pages from the wiki vanished from google
> search results
> Message-ID: <201106012127.19919.lists at roberthogan.net>
> Content-Type: Text/Plain; charset="iso-8859-1"
>
> >
> > Since a couple of days ago (when?), our trac/wiki is not appearing as
> > relevant on google search results anymore.
>
> I noticed this yesteday too, but normal service appears to have been
> restored.
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 1 Jun 2011 13:41:06 -0700
> From: Adam Barth <abarth at webkit.org>
> To: Adam Roben <aroben at apple.com>
> Cc: WebKit Development <webkit-dev at lists.webkit.org>
> Subject: Re: [webkit-dev] New page for viewing test failures on
> build.webkit.org
> Message-ID: <BANLkTikyf_cXPwKv2DFUW+g2Ps8h8s_vHQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Looks like a good start. Have you considered a test-centric view
> (instead of a bot-centric view)? That might make it easier to see
> what's going on globally across the project.
>
> Adam
>
>
> On Wed, Jun 1, 2011 at 12:22 PM, Adam Roben <aroben at apple.com> wrote:
> > Hi all-
> >
> > Before I go on vacation for 2.5 weeks, I wanted to let you know about a
new
> > page I've been working on on build.webkit.org. You can see it here:
> >
> > http://build.webkit.org/TestFailures/
> >
> > The idea of the page is to provide a single place to go to find out what
> > tests are failing on the bots and when they started failing. It also
tries
> > to make it easy to file bugs about the failures.
> >
> > It is pretty ugly, and has some glaring bugs (search Bugzilla for
> > "TestFailures"). But I've found it useful already. I hope you will, too!
> >
> > Please file bugs and feature requests in the Tools / Tests component of
> > Bugzilla, include the word "TestFailures" in the bug, and CC me. The
code
> > lives in
> >
Tools/BuildSlaveSupport/build.webkit.org-config/public_html/TestFailures.
> >
> > Let me know what you think!
> >
> > -Adam
> >
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
>
>
> ------------------------------
>
> Message: 9
> Date: Wed, 1 Jun 2011 17:51:02 -0300
> From: Ademar Reis <ademar.reis at openbossa.org>
> To: Robert Hogan <lists at roberthogan.net>
> Cc: webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] Pages from the wiki vanished from google
> search results
> Message-ID: <BANLkTimLAU4ZHBqj2W2Nb9h2oiROO0hFww at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, Jun 1, 2011 at 5:27 PM, Robert Hogan <lists at roberthogan.net>
wrote:
> >>
> >> Since a couple of days ago (when?), our trac/wiki is not appearing as
> >> relevant on google search results anymore.
> >
> > I noticed this yesteday too, but normal service appears to have been
> > restored.
>
> >From the two original examples I used to test, one is working as
> expected, the other not:
>
> not OK:
>
http://www.google.com/search?hl=en&q=webkit+team+%22Here+is+the+key+for+each%22
>
> OK:
>
http://www.google.com/search?hl=en&q=Qt+Port+of+WebKit+%22List+of+all+QtWebKit+wiki+pages%22
>
> Would be nice if someone with a google-webmaster account could
investigate...
>
> Thanks,
> - Ademar
>
> --
> Ademar de Souza Reis Jr. <ademar.reis at openbossa.org>
> Nokia Institute of Technology
>
>
> ------------------------------
>
> Message: 10
> Date: Wed, 1 Jun 2011 14:27:18 -0700
> From: Brent Fulgham <bfulgham at gmail.com>
> To: Maciej Stachowiak <mjs at apple.com>
> Cc: WebKit-Dev Development <webkit-dev at lists.webkit.org>
> Subject: Re: [webkit-dev] Do we have a style preference about const
> member functions?
> Message-ID: <BANLkTikVMJKci9AauE_AJ8mj1ddAOzN-jw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tue, May 31, 2011 at 11:31 PM, Maciej Stachowiak <mjs at 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 convinced that the following is technically more
correct, though in a way that is completely
> > useless for our code base at present:
> >
> > ?const Node* previousSibling() const { return m_previous; }
> > ?Node* previousSibling() { return m_previous; }
> >
> > What do you think is the right way to do it? One of these? Something
else?
> > [...]
> > Well one big problem right now (just from scanning the core DOM classes)
is that we have a lot of clearly
> > broken use of const. We could (a) leave it as-is, (b) remove the
incorrect use of const, or (c) deploy proper
> > const-correctness. it seems like you are against (b), but I cannot tell
if you advocate (a) or (c).
>
> I would *prefer* to deploy proper const correct accessors, so (c).
>
> However, in the interests of pragmatism I think that it would be
> reasonable to at least remove the improper uses of const (b).
>
> >From the tone of the initial e-mail it sounded like there was some
> desire to get rid of const declarations across the board. I would be
> opposed to this change. However, I concede that improper use of const
> is worse than no const declaration, and would support your (b) case
> (though I would prefer (c)!).
>
> -Brent
>
>
> ------------------------------
>
> Message: 11
> Date: Wed, 1 Jun 2011 17:38:31 -0700
> From: Brian Stuart <Brian at kumatage.com>
> To: webkit-dev at lists.webkit.org
> Subject: [webkit-dev] Different Versions of WebkitSupportLibrary.zip
> Message-ID: <5A6C75F0-8DD3-4782-B532-BACE8CB0E87A at kumatage.com>
> Content-Type: text/plain; charset="windows-1252"
>
> Hi All,
> I am trying to build a fork of WebKit on windows that requires a version
of WebKitSupportLibrary.zip different than the one currently available from
http://developer.apple.com/opensource/internet/webkit_sptlib_agree.html
>
> In the script ?WebKitTools/Scripts/update-webkit-support-libs? it?s
looking for a version of WebKitSupportLibrary.zip with a checksum of
"a1341aadbcce1ef26dad2b2895457314"
>
> Does anyone know where I can download the correct version of
WebKitSupportLibrary.zip?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
http://lists.webkit.org/pipermail/webkit-dev/attachments/20110601/b7005d3c/attachment-0001.html
>
>
> ------------------------------
>
> Message: 12
> Date: Wed, 1 Jun 2011 20:11:26 -0700
> From: James Robinson <jamesr at google.com>
> To: Geoffrey Garen <ggaren at apple.com>
> Cc: Darin Adler <darin at apple.com>, WebKit-Dev Development
> <webkit-dev at lists.webkit.org>
> Subject: Re: [webkit-dev] Do we have a style preference about const
> member functions?
> Message-ID:
> <BANLkTikFh0DpmHX0NG6rPBrMX2+5SvLYwKHcG3i_9uO4D=4k6g at mail.gmail.com
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tue, May 31, 2011 at 12:08 PM, Geoffrey Garen <ggaren at 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!
> >
> >
> > 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 personally find that in a number of render tree functions declared to
take
> a const RenderObject* that the const-ness is a useful hint that the
function
> will not be manipulating the object in unexpected ways. Examples:
>
http://codesearch.google.com/codesearch?hl=en&vert=chromium&lr=&q=%22const+RenderObject%22+file%3AWebCore&sbtn=Search
> (click
> "Next" at the bottom to see more results).
>
> My understanding is that these functions could not take a const
> RenderObject* parameter if RenderObject did not supply a set of const
simple
> accessors and utility functions. We could convert RenderObject over to
have
> no const member functions and convert all of these utility functions to
take
> RenderObject* parameters instead, but I think that would lose some of the
> intent of the code.
>
> 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 causing.
>
> - James
>
> >
> > Geoff
> >
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
http://lists.webkit.org/pipermail/webkit-dev/attachments/20110601/6dc0ed8c/attachment-0001.html
>
>
> ------------------------------
>
> Message: 13
> Date: Thu, 02 Jun 2011 00:38:58 -0700
> From: Maciej Stachowiak <mjs at apple.com>
> To: James Robinson <jamesr at google.com>
> Cc: Darin Adler <darin at apple.com>, WebKit-Dev Development
> <webkit-dev at lists.webkit.org>
> Subject: Re: [webkit-dev] Do we have a style preference about const
> member functions?
> Message-ID: <36ADA179-A0C8-494A-BC0F-69FB58DD5BC3 at apple.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
> On Jun 1, 2011, at 8:11 PM, James Robinson wrote:
>
> > On Tue, May 31, 2011 at 12:08 PM, Geoffrey Garen <ggaren at 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!
> >
> > 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 personally find that in a number of render tree functions declared to
take a const RenderObject* that the const-ness is a useful hint that the
function will not be manipulating the object in unexpected ways. Examples:
> >
http://codesearch.google.com/codesearch?hl=en&vert=chromium&lr=&q=%22const+RenderObject%22+file%3AWebCore&sbtn=Search(click
"Next" at the bottom to see more results).
> >
> > My understanding is that these functions could not take a const
RenderObject* parameter if RenderObject did not supply a set of const simple
accessors and utility functions. We could convert RenderObject over to have
no const member functions and convert all of these utility functions to take
RenderObject* parameters instead, but I think that would lose some of the
intent of the code.
> >
> > 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 causing.
>
> 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 (or that can otherwise get a back pointer). Make the functions
non-const, then add const variants returning a const pointer if needed.
>
> I'm curious if there are any clients for const pointers to DOM nodes.
>
> Regards,
> Maciej
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
http://lists.webkit.org/pipermail/webkit-dev/attachments/20110602/57e1d1a0/attachment-0001.html
>
>
> ------------------------------
>
> Message: 14
> Date: Thu, 2 Jun 2011 01:21:59 -0700
> From: Ryosuke Niwa <rniwa at webkit.org>
> To: Geoffrey Garen <ggaren at apple.com>
> Cc: Darin Adler <darin at apple.com>, WebKit-Dev Development
> <webkit-dev at lists.webkit.org>
> Subject: Re: [webkit-dev] Do we have a style preference about const
> member functions?
> Message-ID: <BANLkTinoJ+DeCr-v80LmFuGyFSkaJQRnSw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tue, May 31, 2011 at 12:08 PM, Geoffrey Garen <ggaren at 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 that meaningfully uses a
const
> > pointer or reference? (Something other than, say, the obligatory const&
in a
> > copy constructor.)
> >
>
> I think const reference to String and const pointers to
> CSSStyleDeclaration/CSSMutableStyleDeclaration are good examples.
>
> - Ryosuke
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
http://lists.webkit.org/pipermail/webkit-dev/attachments/20110602/0d0e4800/attachment-0001.html
>
>
> ------------------------------
>
> Message: 15
> Date: Thu, 2 Jun 2011 16:29:15 +0800
> From: Hao Zheng <zhenghao at chromium.org>
> To: WebKit Development <webkit-dev at lists.webkit.org>
> Subject: Re: [webkit-dev] Cross-platform fonts for Layout Tests
> Message-ID: <BANLkTikXO4PJq40ZPV7pcptcAzYezaZzmQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Actually, even the same Ahem font will be rendered differently on
> different platform, depending on the font drawing library, the
> anti-aliasing algorithm, subpixel, tiny float-point calculation diff
> on different arch.
>
> On Thu, Jun 2, 2011 at 3:30 AM, Eric Seidel <eric at webkit.org> wrote:
> > I know that Ahem is safe to use across multiple platforms (the font
metrics
> > will be the same). ?Do we know if there are any other fonts for which
this
> > is true?
> > I'd like to make the style-bot yell at people when they use pixel tests
with
> > non-safe fonts. ?Right now that list would only include ahem.
> > -eric
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
>
>
> ------------------------------
>
> Message: 16
> Date: Thu, 2 Jun 2011 01:32:01 -0700
> From: Ryosuke Niwa <rniwa at webkit.org>
> To: Maciej Stachowiak <mjs at apple.com>
> Cc: Darin Adler <darin at apple.com>, WebKit-Dev Development
> <webkit-dev at lists.webkit.org>
> Subject: Re: [webkit-dev] Do we have a style preference about const
> member functions?
> Message-ID: <BANLkTimvQzfxJMRrQx5DviApbP=N3O1KRQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu, Jun 2, 2011 at 12:38 AM, Maciej Stachowiak <mjs at apple.com> 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 (or that can otherwise get a back pointer). Make the functions
> > non-const, then add const variants returning a const pointer if needed.
> >
> > I'm curious if there are any clients for const pointers to DOM nodes.
> >
>
> 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 pointer to a DOM node. It is
*
> critical *that nodeIsOfType does not modify DOM because we use a raw
pointer
> to keep track of the current node when walking up the tree.
>
> - Ryosuke
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
http://lists.webkit.org/pipermail/webkit-dev/attachments/20110602/fdfa9c1d/attachment-0001.html
>
>
> ------------------------------
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
> End of webkit-dev Digest, Vol 73, Issue 2
> *****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110603/47075260/attachment.html>
More information about the webkit-dev
mailing list