<p>Thanks.<br>
On Jun 2, 2011 11:00 PM, <<a href="mailto:webkit-dev-request@lists.webkit.org">webkit-dev-request@lists.webkit.org</a>> wrote:<br>
><br>
> Send webkit-dev mailing list submissions to<br>
>        <a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
><br>
> To subscribe or unsubscribe via the World Wide Web, visit<br>
>        <a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
> or, via email, send a message with subject or body 'help' to<br>
>        <a href="mailto:webkit-dev-request@lists.webkit.org">webkit-dev-request@lists.webkit.org</a><br>
><br>
> You can reach the person managing the list at<br>
>        <a href="mailto:webkit-dev-owner@lists.webkit.org">webkit-dev-owner@lists.webkit.org</a><br>
><br>
> When replying, please edit your Subject line so it is more specific<br>
> than "Re: Contents of webkit-dev digest..."<br>
><br>
><br>
> Today's Topics:<br>
><br>
>   1. Re: Issue Analysis:48290 [HTML Canvas<br>
>      globalCompositeOperation] (Darin Adler)<br>
>   2. Re: Issue Analysis:48290 [HTML Canvas<br>
>      globalCompositeOperation] (Mustafizur Rahaman)<br>
>   3. Re: Issue Analysis:48290 [HTML Canvas<br>
>      globalCompositeOperation] (Darin Adler)<br>
>   4. New page for viewing test failures on <a href="http://build.webkit.org">build.webkit.org</a><br>
>      (Adam Roben)<br>
>   5. Cross-platform fonts for Layout Tests (Eric Seidel)<br>
>   6. Re: Do we have a style preference about const member<br>
>      functions? (Peter Kasting)<br>
>   7. Re: Pages from the wiki vanished from google search       results<br>
>      (Robert Hogan)<br>
>   8. Re: New page for viewing test failures on <a href="http://build.webkit.org">build.webkit.org</a><br>
>      (Adam Barth)<br>
>   9. Re: Pages from the wiki vanished from google search       results<br>
>      (Ademar Reis)<br>
>  10. Re: Do we have a style preference about const member<br>
>      functions? (Brent Fulgham)<br>
>  11. Different Versions of WebkitSupportLibrary.zip (Brian Stuart)<br>
>  12. Re: Do we have a style preference about const member<br>
>      functions? (James Robinson)<br>
>  13. Re: Do we have a style preference about const member<br>
>      functions? (Maciej Stachowiak)<br>
>  14. Re: Do we have a style preference about const member<br>
>      functions? (Ryosuke Niwa)<br>
>  15. Re: Cross-platform fonts for Layout Tests (Hao Zheng)<br>
>  16. Re: Do we have a style preference about const member<br>
>      functions? (Ryosuke Niwa)<br>
><br>
><br>
> ----------------------------------------------------------------------<br>
><br>
> Message: 1<br>
> Date: Wed, 01 Jun 2011 09:21:09 -0700<br>
> From: Darin Adler <<a href="mailto:darin@apple.com">darin@apple.com</a>><br>
> To: Karthik <<a href="mailto:sarap.karthik@gmail.com">sarap.karthik@gmail.com</a>><br>
> Cc: <a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
> Subject: Re: [webkit-dev] Issue Analysis:48290 [HTML Canvas<br>
>        globalCompositeOperation]<br>
> Message-ID: <<a href="mailto:73B9726E-9D07-4252-8893-906E21F25E4B@apple.com">73B9726E-9D07-4252-8893-906E21F25E4B@apple.com</a>><br>
> Content-Type: text/plain; charset=windows-1252<br>
><br>
> On May 31, 2011, at 11:49 PM, Karthik wrote:<br>
><br>
> > 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.<br>

><br>
> We can remove that comment. It?s obsolete.<br>
><br>
> 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.<br>
><br>
> 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.<br>

><br>
> 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.<br>
><br>
> 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.<br>
><br>
>    -- Darin<br>
><br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 2<br>
> Date: Wed, 1 Jun 2011 22:44:20 +0530<br>
> From: Mustafizur Rahaman <<a href="mailto:mustaf.here@gmail.com">mustaf.here@gmail.com</a>><br>
> To: Darin Adler <<a href="mailto:darin@apple.com">darin@apple.com</a>><br>
> Cc: <a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
> Subject: Re: [webkit-dev] Issue Analysis:48290 [HTML Canvas<br>
>        globalCompositeOperation]<br>
> Message-ID: <BANLkTi=<a href="mailto:J1gBxf%2Buuue%2BTW6Amv4zN_TWeEA@mail.gmail.com">J1gBxf+uuue+TW6Amv4zN_TWeEA@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="windows-1252"<br>
><br>
> Hi Darin,<br>
><br>
> Thanks for your detailed explanation. Initially we decided to remove the<br>
> string as well the enum to fix this issue. But Karthik's patch (we have<br>
> already submitted the patch in<br>
> <a href="https://bugs.webkit.org/show_bug.cgi?id=48290">https://bugs.webkit.org/show_bug.cgi?id=48290</a>) caused a Chromium build<br>
> issue & then we found that this enum is used in<br>
> lot of other places. So, we were a little apprehensive about the side effect<br>
> of this fix.<br>
><br>
> Therefore, we submitted another patch where we are returning from the canvas<br>
> code itself if the compositing mode is "highlight". We are still waiting for<br>
> the review comments.<br>
><br>
> Similar issue (<a href="https://bugs.webkit.org/show_bug.cgi?id=48289">https://bugs.webkit.org/show_bug.cgi?id=48289</a> ) we have also<br>
> seen for "darker"/CompositePlusDarker (not a valid compositing mode any<br>
> more). Can we also remove this as well?<br>
><br>
> Thanks,<br>
> Rahaman<br>
><br>
> On Wed, Jun 1, 2011 at 9:51 PM, Darin Adler <<a href="mailto:darin@apple.com">darin@apple.com</a>> wrote:<br>
><br>
> > On May 31, 2011, at 11:49 PM, Karthik wrote:<br>
> ><br>
> > > However, the following comment was mentioned in GraphicsType.h ("    //<br>
> > Note: These constants exactly match the NSCompositeOperator constants of //<br>
> > AppKit on Mac OS X Tiger. If these ever change, we'll need to change the //<br>
> > Mac OS X Tiger platform code to map one to the other. "). So I am little<br>
> > unclear what is the purpose of this CompositeHighLight.<br>
> ><br>
> > We can remove that comment. It?s obsolete.<br>
> ><br>
> > I believe the ?highlight? compositing mode used to be supported in canvas<br>
> > by WebKit on Mac, but hasn?t been for some time. There?s probably no harm in<br>
> > removing it now.<br>
> ><br>
> > The fact that the string is ?not valid? in the specification isn?t what<br>
> > makes it OK to remove. Please remember that the canvas implementation in<br>
> > WebKit was the first and predates the specification by at least a year. But<br>
> > it?s almost certainly OK to remove this compositing mode because it hasn?t<br>
> > been implemented for quite a while.<br>
> ><br>
> > There?s still a slim chance that there is some content out there relying on<br>
> > ?highlight? being a synonym for ?source-over?, but it?s not likely.<br>
> ><br>
> > One side comment: I think the mapping from strings to the various graphics<br>
> > enums really belongs in the canvas code, not in the platform directory.<br>
> ><br>
> >    -- Darin<br>
> ><br>
> > _______________________________________________<br>
> > webkit-dev mailing list<br>
> > <a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
> > <a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
> ><br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<a href="http://lists.webkit.org/pipermail/webkit-dev/attachments/20110601/86e812e9/attachment-0001.html">http://lists.webkit.org/pipermail/webkit-dev/attachments/20110601/86e812e9/attachment-0001.html</a>><br>

><br>
> ------------------------------<br>
><br>
> Message: 3<br>
> Date: Wed, 01 Jun 2011 10:19:50 -0700<br>
> From: Darin Adler <<a href="mailto:darin@apple.com">darin@apple.com</a>><br>
> To: Mustafizur Rahaman <<a href="mailto:mustaf.here@gmail.com">mustaf.here@gmail.com</a>><br>
> Cc: <a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
> Subject: Re: [webkit-dev] Issue Analysis:48290 [HTML Canvas<br>
>        globalCompositeOperation]<br>
> Message-ID: <<a href="mailto:EB93C273-0C72-4D61-9988-D34499897FD2@apple.com">EB93C273-0C72-4D61-9988-D34499897FD2@apple.com</a>><br>
> Content-Type: text/plain; charset="windows-1252"<br>
><br>
> On Jun 1, 2011, at 10:14 AM, Mustafizur Rahaman wrote:<br>
><br>
> > Therefore, we submitted another patch where we are returning from the canvas code itself if the compositing mode is "highlight".<br>
><br>
> That?s not a good idea. We should keep looking into the real fix; that kind of hack is unneeded here.<br>
><br>
> > Similar issue (<a href="https://bugs.webkit.org/show_bug.cgi?id=48289">https://bugs.webkit.org/show_bug.cgi?id=48289</a> ) we have also seen for "darker"/CompositePlusDarker (not a valid compositing mode any more). Can we also remove this as well?<br>

><br>
> 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.<br>
><br>
>    -- Darin<br>
><br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<a href="http://lists.webkit.org/pipermail/webkit-dev/attachments/20110601/fb6bed1a/attachment-0001.html">http://lists.webkit.org/pipermail/webkit-dev/attachments/20110601/fb6bed1a/attachment-0001.html</a>><br>

><br>
> ------------------------------<br>
><br>
> Message: 4<br>
> Date: Wed, 01 Jun 2011 15:22:25 -0400<br>
> From: Adam Roben <<a href="mailto:aroben@apple.com">aroben@apple.com</a>><br>
> To: WebKit Development <<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a>><br>
> Subject: [webkit-dev] New page for viewing test failures on<br>
>        <a href="http://build.webkit.org">build.webkit.org</a><br>
> Message-ID: <<a href="mailto:3EF00935-A83E-4F51-B9F4-1AE7B63339CD@apple.com">3EF00935-A83E-4F51-B9F4-1AE7B63339CD@apple.com</a>><br>
> Content-Type: text/plain; CHARSET=US-ASCII; format=flowed; delsp=yes<br>
><br>
> Hi all-<br>
><br>
> Before I go on vacation for 2.5 weeks, I wanted to let you know about<br>
> a new page I've been working on on <a href="http://build.webkit.org">build.webkit.org</a>. You can see it<br>
> here:<br>
><br>
> <a href="http://build.webkit.org/TestFailures/">http://build.webkit.org/TestFailures/</a><br>
><br>
> The idea of the page is to provide a single place to go to find out<br>
> what tests are failing on the bots and when they started failing. It<br>
> also tries to make it easy to file bugs about the failures.<br>
><br>
> It is pretty ugly, and has some glaring bugs (search Bugzilla for<br>
> "TestFailures"). But I've found it useful already. I hope you will, too!<br>
><br>
> Please file bugs and feature requests in the Tools / Tests component<br>
> of Bugzilla, include the word "TestFailures" in the bug, and CC me.<br>
> The code lives in Tools/BuildSlaveSupport/build.webkit.org-config/<br>
> public_html/TestFailures.<br>
><br>
> Let me know what you think!<br>
><br>
> -Adam<br>
><br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 5<br>
> Date: Wed, 1 Jun 2011 12:30:04 -0700<br>
> From: Eric Seidel <<a href="mailto:eric@webkit.org">eric@webkit.org</a>><br>
> To: WebKit Development <<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a>><br>
> Subject: [webkit-dev] Cross-platform fonts for Layout Tests<br>
> Message-ID: <BANLkTik5Ku0Bm87Ruz8ZPzZd_9q=<a href="mailto:8ntsHw@mail.gmail.com">8ntsHw@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="iso-8859-1"<br>
><br>
> I know that Ahem is safe to use across multiple platforms (the font metrics<br>
> will be the same).  Do we know if there are any other fonts for which this<br>
> is true?<br>
><br>
> I'd like to make the style-bot yell at people when they use pixel tests with<br>
> non-safe fonts.  Right now that list would only include ahem.<br>
><br>
> -eric<br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<a href="http://lists.webkit.org/pipermail/webkit-dev/attachments/20110601/fb75b783/attachment-0001.html">http://lists.webkit.org/pipermail/webkit-dev/attachments/20110601/fb75b783/attachment-0001.html</a>><br>

><br>
> ------------------------------<br>
><br>
> Message: 6<br>
> Date: Wed, 1 Jun 2011 13:20:28 -0700<br>
> From: Peter Kasting <<a href="mailto:pkasting@chromium.org">pkasting@chromium.org</a>><br>
> To: Maciej Stachowiak <<a href="mailto:mjs@apple.com">mjs@apple.com</a>><br>
> Cc: WebKit-Dev Development <<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a>><br>
> Subject: Re: [webkit-dev] Do we have a style preference about const<br>
>        member  functions?<br>
> Message-ID: <BANLkTim2mEB7WE9=<a href="mailto:pBDR3EMPXt9s8p%2BHXQ@mail.gmail.com">pBDR3EMPXt9s8p+HXQ@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="iso-8859-1"<br>
><br>
> On Tue, May 31, 2011 at 11:31 PM, Maciej Stachowiak <<a href="mailto:mjs@apple.com">mjs@apple.com</a>> wrote:<br>
><br>
> > The following would be valid but would require us to cast away const all<br>
> > over the place and would therefore in my opinion be a net negative:<br>
> ><br>
> >  const Node* previousSibling() const { return m_previous; }<br>
> ><br>
> > And what's in our code now violates the intent of const, and so to me at<br>
> > least is clearly a bug:<br>
> ><br>
> >  Node* previousSibling() const { return m_previous; }<br>
> ><br>
><br>
> I agree that these are both bad.<br>
><br>
> Well one big problem right now (just from scanning the core DOM classes) is<br>
> > that we have a lot of clearly broken use of const. We could (a) leave it<br>
> > as-is, (b) remove the incorrect use of const, or (c) deploy proper<br>
> > const-correctness. it seems like you are against (b), but I cannot tell if<br>
> > you advocate (a) or (c).<br>
> ><br>
><br>
> Misusing const is IMO worse than not using const.  I would be in favor of<br>
> removing cases like the last one you cite above, as well as working to<br>
> remove const_casts, at least where they indicate problems.<br>
><br>
> It would be nice to make things more properly const-correct, and make<br>
> callers use const accessors when possible (e.g. use the const form of tree<br>
> iteration when walking a tree merely to read data and not write it), so I<br>
> don't think we should forbid good use of const, but it's also time-consuming<br>
> to retrofit.<br>
><br>
> Perhaps we could at least encourage const-correctness for newly-written<br>
> classes?  By this I mean both adherence to the logical-constness rules you<br>
> stated earlier as well as not adding non-const accessors and members unless<br>
> needed -- otherwise it's easy to just err on the side of never using const<br>
> anywhere.<br>
><br>
> I also think we should not discourage people from using "const" on<br>
> variables.  I've gotten review comments in the past that have asked me to<br>
> remove const qualifiers on locals, as well as sometimes on arguments and<br>
> members, and I think this is a mistake.  "We aren't const-correct elsewhere<br>
> in WebCore" is not a good reason to forbid const.<br>
><br>
> PK<br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<a href="http://lists.webkit.org/pipermail/webkit-dev/attachments/20110601/1f2bda88/attachment-0001.html">http://lists.webkit.org/pipermail/webkit-dev/attachments/20110601/1f2bda88/attachment-0001.html</a>><br>

><br>
> ------------------------------<br>
><br>
> Message: 7<br>
> Date: Wed, 1 Jun 2011 21:27:17 +0100<br>
> From: Robert Hogan <<a href="mailto:lists@roberthogan.net">lists@roberthogan.net</a>><br>
> To: <a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
> Subject: Re: [webkit-dev] Pages from the wiki vanished from google<br>
>        search  results<br>
> Message-ID: <<a href="mailto:201106012127.19919.lists@roberthogan.net">201106012127.19919.lists@roberthogan.net</a>><br>
> Content-Type: Text/Plain;  charset="iso-8859-1"<br>
><br>
> ><br>
> > Since a couple of days ago (when?), our trac/wiki is not appearing as<br>
> > relevant on google search results anymore.<br>
><br>
> I noticed this yesteday too, but normal service appears to have been<br>
> restored.<br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 8<br>
> Date: Wed, 1 Jun 2011 13:41:06 -0700<br>
> From: Adam Barth <<a href="mailto:abarth@webkit.org">abarth@webkit.org</a>><br>
> To: Adam Roben <<a href="mailto:aroben@apple.com">aroben@apple.com</a>><br>
> Cc: WebKit Development <<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a>><br>
> Subject: Re: [webkit-dev] New page for viewing test failures on<br>
>        <a href="http://build.webkit.org">build.webkit.org</a><br>
> Message-ID: <<a href="mailto:BANLkTikyf_cXPwKv2DFUW%2Bg2Ps8h8s_vHQ@mail.gmail.com">BANLkTikyf_cXPwKv2DFUW+g2Ps8h8s_vHQ@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset=ISO-8859-1<br>
><br>
> Looks like a good start.  Have you considered a test-centric view<br>
> (instead of a bot-centric view)?  That might make it easier to see<br>
> what's going on globally across the project.<br>
><br>
> Adam<br>
><br>
><br>
> On Wed, Jun 1, 2011 at 12:22 PM, Adam Roben <<a href="mailto:aroben@apple.com">aroben@apple.com</a>> wrote:<br>
> > Hi all-<br>
> ><br>
> > Before I go on vacation for 2.5 weeks, I wanted to let you know about a new<br>
> > page I've been working on on <a href="http://build.webkit.org">build.webkit.org</a>. You can see it here:<br>
> ><br>
> > <a href="http://build.webkit.org/TestFailures/">http://build.webkit.org/TestFailures/</a><br>
> ><br>
> > The idea of the page is to provide a single place to go to find out what<br>
> > tests are failing on the bots and when they started failing. It also tries<br>
> > to make it easy to file bugs about the failures.<br>
> ><br>
> > It is pretty ugly, and has some glaring bugs (search Bugzilla for<br>
> > "TestFailures"). But I've found it useful already. I hope you will, too!<br>
> ><br>
> > Please file bugs and feature requests in the Tools / Tests component of<br>
> > Bugzilla, include the word "TestFailures" in the bug, and CC me. The code<br>
> > lives in<br>
> > Tools/BuildSlaveSupport/build.webkit.org-config/public_html/TestFailures.<br>
> ><br>
> > Let me know what you think!<br>
> ><br>
> > -Adam<br>
> ><br>
> > _______________________________________________<br>
> > webkit-dev mailing list<br>
> > <a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
> > <a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
> ><br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 9<br>
> Date: Wed, 1 Jun 2011 17:51:02 -0300<br>
> From: Ademar Reis <<a href="mailto:ademar.reis@openbossa.org">ademar.reis@openbossa.org</a>><br>
> To: Robert Hogan <<a href="mailto:lists@roberthogan.net">lists@roberthogan.net</a>><br>
> Cc: <a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
> Subject: Re: [webkit-dev] Pages from the wiki vanished from google<br>
>        search  results<br>
> Message-ID: <<a href="mailto:BANLkTimLAU4ZHBqj2W2Nb9h2oiROO0hFww@mail.gmail.com">BANLkTimLAU4ZHBqj2W2Nb9h2oiROO0hFww@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset=UTF-8<br>
><br>
> On Wed, Jun 1, 2011 at 5:27 PM, Robert Hogan <<a href="mailto:lists@roberthogan.net">lists@roberthogan.net</a>> wrote:<br>
> >><br>
> >> Since a couple of days ago (when?), our trac/wiki is not appearing as<br>
> >> relevant on google search results anymore.<br>
> ><br>
> > I noticed this yesteday too, but normal service appears to have been<br>
> > restored.<br>
><br>
> >From the two original examples I used to test, one is working as<br>
> expected, the other not:<br>
><br>
> not OK:<br>
> <a href="http://www.google.com/search?hl=en&q=webkit+team+%22Here+is+the+key+for+each%22">http://www.google.com/search?hl=en&q=webkit+team+%22Here+is+the+key+for+each%22</a><br>
><br>
> OK:<br>
> <a href="http://www.google.com/search?hl=en&q=Qt+Port+of+WebKit+%22List+of+all+QtWebKit+wiki+pages%22">http://www.google.com/search?hl=en&q=Qt+Port+of+WebKit+%22List+of+all+QtWebKit+wiki+pages%22</a><br>
><br>
> Would be nice if someone with a google-webmaster account could investigate...<br>
><br>
> Thanks,<br>
>   - Ademar<br>
><br>
> --<br>
> Ademar de Souza Reis Jr. <<a href="mailto:ademar.reis@openbossa.org">ademar.reis@openbossa.org</a>><br>
> Nokia Institute of Technology<br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 10<br>
> Date: Wed, 1 Jun 2011 14:27:18 -0700<br>
> From: Brent Fulgham <<a href="mailto:bfulgham@gmail.com">bfulgham@gmail.com</a>><br>
> To: Maciej Stachowiak <<a href="mailto:mjs@apple.com">mjs@apple.com</a>><br>
> Cc: WebKit-Dev Development <<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a>><br>
> Subject: Re: [webkit-dev] Do we have a style preference about const<br>
>        member  functions?<br>
> Message-ID: <<a href="mailto:BANLkTikVMJKci9AauE_AJ8mj1ddAOzN-jw@mail.gmail.com">BANLkTikVMJKci9AauE_AJ8mj1ddAOzN-jw@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset=ISO-8859-1<br>
><br>
> On Tue, May 31, 2011 at 11:31 PM, Maciej Stachowiak <<a href="mailto:mjs@apple.com">mjs@apple.com</a>> wrote:<br>
> > [...] What do you believe is the proper const-correct way to write previousSibling() and related methods?<br>
> > A priori, I think the correct way is this:<br>
> ><br>
> > ?Node* previousSibling() { return m_previous; }<br>
> ><br>
> > I could also be convinced that the following is technically more correct, though in a way that is completely<br>
> > useless for our code base at present:<br>
> ><br>
> > ?const Node* previousSibling() const { return m_previous; }<br>
> > ?Node* previousSibling() { return m_previous; }<br>
> ><br>
> > What do you think is the right way to do it? One of these? Something else?<br>
> > [...]<br>
> > Well one big problem right now (just from scanning the core DOM classes) is that we have a lot of clearly<br>
> > broken use of const. We could (a) leave it as-is, (b) remove the incorrect use of const, or (c) deploy proper<br>
> > const-correctness. it seems like you are against (b), but I cannot tell if you advocate (a) or (c).<br>
><br>
> I would *prefer* to deploy proper const correct accessors, so (c).<br>
><br>
> However, in the interests of pragmatism I think that it would be<br>
> reasonable to at least remove the improper uses of const (b).<br>
><br>
> >From the tone of the initial e-mail it sounded like there was some<br>
> desire to get rid of const declarations across the board.  I would be<br>
> opposed to this change.  However, I concede that improper use of const<br>
> is worse than no const declaration, and would support your (b) case<br>
> (though I would prefer (c)!).<br>
><br>
> -Brent<br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 11<br>
> Date: Wed, 1 Jun 2011 17:38:31 -0700<br>
> From: Brian Stuart <<a href="mailto:Brian@kumatage.com">Brian@kumatage.com</a>><br>
> To: <a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
> Subject: [webkit-dev] Different Versions of WebkitSupportLibrary.zip<br>
> Message-ID: <<a href="mailto:5A6C75F0-8DD3-4782-B532-BACE8CB0E87A@kumatage.com">5A6C75F0-8DD3-4782-B532-BACE8CB0E87A@kumatage.com</a>><br>
> Content-Type: text/plain; charset="windows-1252"<br>
><br>
> Hi All,<br>
> 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 <a href="http://developer.apple.com/opensource/internet/webkit_sptlib_agree.html">http://developer.apple.com/opensource/internet/webkit_sptlib_agree.html</a><br>

><br>
> In the script ?WebKitTools/Scripts/update-webkit-support-libs? it?s looking for a version of WebKitSupportLibrary.zip with a checksum of "a1341aadbcce1ef26dad2b2895457314"<br>
><br>
> Does anyone know where I can download the correct version of WebKitSupportLibrary.zip?<br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<a href="http://lists.webkit.org/pipermail/webkit-dev/attachments/20110601/b7005d3c/attachment-0001.html">http://lists.webkit.org/pipermail/webkit-dev/attachments/20110601/b7005d3c/attachment-0001.html</a>><br>

><br>
> ------------------------------<br>
><br>
> Message: 12<br>
> Date: Wed, 1 Jun 2011 20:11:26 -0700<br>
> From: James Robinson <<a href="mailto:jamesr@google.com">jamesr@google.com</a>><br>
> To: Geoffrey Garen <<a href="mailto:ggaren@apple.com">ggaren@apple.com</a>><br>
> Cc: Darin Adler <<a href="mailto:darin@apple.com">darin@apple.com</a>>,      WebKit-Dev Development<br>
>        <<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a>><br>
> Subject: Re: [webkit-dev] Do we have a style preference about const<br>
>        member  functions?<br>
> Message-ID:<br>
>        <BANLkTikFh0DpmHX0NG6rPBrMX2+5SvLYwKHcG3i_9uO4D=<a href="mailto:4k6g@mail.gmail.com">4k6g@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="iso-8859-1"<br>
><br>
> On Tue, May 31, 2011 at 12:08 PM, Geoffrey Garen <<a href="mailto:ggaren@apple.com">ggaren@apple.com</a>> wrote:<br>
><br>
> > I agree that const should be used for "logical constness". The rule should<br>
> >> not be merely "doesn't alter any data members of this object" but rather<br>
> >> "does not alter observable state of this object or vend any type of pointer<br>
> >> or reference by which observable state of this object could be altered".<br>
> >><br>
> ><br>
> > Precisely!<br>
> ><br>
> ><br>
> > I like this explanation too.<br>
> ><br>
> > I'm trying to think of a simple way to explain / test whether something<br>
> > falls into the category of logical constness, since it can be ambiguous.<br>
> ><br>
> > It occurred to me that a simple, though imperfect, test is just, "Is this<br>
> > function called by an owner of a const pointer / reference?" After all, a<br>
> > const member function is meaningless if nobody points to the class through a<br>
> > const pointer  / reference. For classes like DOM and render tree nodes,<br>
> > which have no meaningful const-pointer-owning clients, the answer is always<br>
> > no. For other classes, the answer is yes, but only if someone has found a<br>
> > meaningful use for a const pointer or reference to the class.<br>
> ><br>
> > So, perhaps the real style question we should answer is when to use const<br>
> > pointers / references, since the answer to when to use const member<br>
> > functions will follow from it.<br>
> ><br>
> > What are some good examples of existing code that meaningfully uses a const<br>
> > pointer or reference? (Something other than, say, the obligatory const& in a<br>
> > copy constructor.)<br>
> ><br>
><br>
> I personally find that in a number of render tree functions declared to take<br>
> a const RenderObject* that the const-ness is a useful hint that the function<br>
> will not be manipulating the object in unexpected ways.  Examples:<br>
> <a href="http://codesearch.google.com/codesearch?hl=en&vert=chromium&lr=&q=%22const+RenderObject%22+file%3AWebCore&sbtn=Search">http://codesearch.google.com/codesearch?hl=en&vert=chromium&lr=&q=%22const+RenderObject%22+file%3AWebCore&sbtn=Search</a><br>

> (click<br>
> "Next" at the bottom to see more results).<br>
><br>
> My understanding is that these functions could not take a const<br>
> RenderObject* parameter if RenderObject did not supply a set of const simple<br>
> accessors and utility functions.  We could convert RenderObject over to have<br>
> no const member functions and convert all of these utility functions to take<br>
> RenderObject* parameters instead, but I think that would lose some of the<br>
> intent of the code.<br>
><br>
> I'm curious if there was a specific patch or piece of code that lead you to<br>
> send this email out - perhaps we make a better decision about whether to<br>
> change our approach with more concrete examples of problems the current<br>
> situation has caused or is causing.<br>
><br>
> - James<br>
><br>
> ><br>
> > Geoff<br>
> ><br>
> > _______________________________________________<br>
> > webkit-dev mailing list<br>
> > <a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
> > <a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
> ><br>
> ><br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<a href="http://lists.webkit.org/pipermail/webkit-dev/attachments/20110601/6dc0ed8c/attachment-0001.html">http://lists.webkit.org/pipermail/webkit-dev/attachments/20110601/6dc0ed8c/attachment-0001.html</a>><br>

><br>
> ------------------------------<br>
><br>
> Message: 13<br>
> Date: Thu, 02 Jun 2011 00:38:58 -0700<br>
> From: Maciej Stachowiak <<a href="mailto:mjs@apple.com">mjs@apple.com</a>><br>
> To: James Robinson <<a href="mailto:jamesr@google.com">jamesr@google.com</a>><br>
> Cc: Darin Adler <<a href="mailto:darin@apple.com">darin@apple.com</a>>,      WebKit-Dev Development<br>
>        <<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a>><br>
> Subject: Re: [webkit-dev] Do we have a style preference about const<br>
>        member functions?<br>
> Message-ID: <<a href="mailto:36ADA179-A0C8-494A-BC0F-69FB58DD5BC3@apple.com">36ADA179-A0C8-494A-BC0F-69FB58DD5BC3@apple.com</a>><br>
> Content-Type: text/plain; charset="us-ascii"<br>
><br>
><br>
> On Jun 1, 2011, at 8:11 PM, James Robinson wrote:<br>
><br>
> > On Tue, May 31, 2011 at 12:08 PM, Geoffrey Garen <<a href="mailto:ggaren@apple.com">ggaren@apple.com</a>> wrote:<br>
> >> 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".<br>

> >><br>
> >> Precisely!<br>
> ><br>
> > I like this explanation too.<br>
> ><br>
> > 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.<br>
> ><br>
> > 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.<br>

> ><br>
> > 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.<br>
> ><br>
> > 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.)<br>
> ><br>
> > 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:<br>

> > <a href="http://codesearch.google.com/codesearch?hl=en&vert=chromium&lr=&q=%22const+RenderObject%22+file%3AWebCore&sbtn=Search">http://codesearch.google.com/codesearch?hl=en&vert=chromium&lr=&q=%22const+RenderObject%22+file%3AWebCore&sbtn=Search</a> (click "Next" at the bottom to see more results).<br>

> ><br>
> > 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.<br>

> ><br>
> > 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.<br>

><br>
> 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.<br>

><br>
> I'm curious if there are any clients for const pointers to DOM nodes.<br>
><br>
> Regards,<br>
> Maciej<br>
><br>
><br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<a href="http://lists.webkit.org/pipermail/webkit-dev/attachments/20110602/57e1d1a0/attachment-0001.html">http://lists.webkit.org/pipermail/webkit-dev/attachments/20110602/57e1d1a0/attachment-0001.html</a>><br>

><br>
> ------------------------------<br>
><br>
> Message: 14<br>
> Date: Thu, 2 Jun 2011 01:21:59 -0700<br>
> From: Ryosuke Niwa <<a href="mailto:rniwa@webkit.org">rniwa@webkit.org</a>><br>
> To: Geoffrey Garen <<a href="mailto:ggaren@apple.com">ggaren@apple.com</a>><br>
> Cc: Darin Adler <<a href="mailto:darin@apple.com">darin@apple.com</a>>,      WebKit-Dev Development<br>
>        <<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a>><br>
> Subject: Re: [webkit-dev] Do we have a style preference about const<br>
>        member  functions?<br>
> Message-ID: <<a href="mailto:BANLkTinoJ%2BDeCr-v80LmFuGyFSkaJQRnSw@mail.gmail.com">BANLkTinoJ+DeCr-v80LmFuGyFSkaJQRnSw@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="iso-8859-1"<br>
><br>
> On Tue, May 31, 2011 at 12:08 PM, Geoffrey Garen <<a href="mailto:ggaren@apple.com">ggaren@apple.com</a>> wrote:<br>
> ><br>
> > So, perhaps the real style question we should answer is when to use const<br>
> > pointers / references, since the answer to when to use const member<br>
> > functions will follow from it.<br>
> ><br>
> > What are some good examples of existing code that meaningfully uses a const<br>
> > pointer or reference? (Something other than, say, the obligatory const& in a<br>
> > copy constructor.)<br>
> ><br>
><br>
> I think const reference to String and const pointers to<br>
> CSSStyleDeclaration/CSSMutableStyleDeclaration are good examples.<br>
><br>
> - Ryosuke<br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<a href="http://lists.webkit.org/pipermail/webkit-dev/attachments/20110602/0d0e4800/attachment-0001.html">http://lists.webkit.org/pipermail/webkit-dev/attachments/20110602/0d0e4800/attachment-0001.html</a>><br>

><br>
> ------------------------------<br>
><br>
> Message: 15<br>
> Date: Thu, 2 Jun 2011 16:29:15 +0800<br>
> From: Hao Zheng <<a href="mailto:zhenghao@chromium.org">zhenghao@chromium.org</a>><br>
> To: WebKit Development <<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a>><br>
> Subject: Re: [webkit-dev] Cross-platform fonts for Layout Tests<br>
> Message-ID: <<a href="mailto:BANLkTikXO4PJq40ZPV7pcptcAzYezaZzmQ@mail.gmail.com">BANLkTikXO4PJq40ZPV7pcptcAzYezaZzmQ@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset=ISO-8859-1<br>
><br>
> Actually, even the same Ahem font will be rendered differently on<br>
> different platform, depending on the font drawing library, the<br>
> anti-aliasing algorithm, subpixel, tiny float-point calculation diff<br>
> on different arch.<br>
><br>
> On Thu, Jun 2, 2011 at 3:30 AM, Eric Seidel <<a href="mailto:eric@webkit.org">eric@webkit.org</a>> wrote:<br>
> > I know that Ahem is safe to use across multiple platforms (the font metrics<br>
> > will be the same). ?Do we know if there are any other fonts for which this<br>
> > is true?<br>
> > I'd like to make the style-bot yell at people when they use pixel tests with<br>
> > non-safe fonts. ?Right now that list would only include ahem.<br>
> > -eric<br>
> > _______________________________________________<br>
> > webkit-dev mailing list<br>
> > <a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
> > <a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
> ><br>
> ><br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 16<br>
> Date: Thu, 2 Jun 2011 01:32:01 -0700<br>
> From: Ryosuke Niwa <<a href="mailto:rniwa@webkit.org">rniwa@webkit.org</a>><br>
> To: Maciej Stachowiak <<a href="mailto:mjs@apple.com">mjs@apple.com</a>><br>
> Cc: Darin Adler <<a href="mailto:darin@apple.com">darin@apple.com</a>>,      WebKit-Dev Development<br>
>        <<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a>><br>
> Subject: Re: [webkit-dev] Do we have a style preference about const<br>
>        member  functions?<br>
> Message-ID: <BANLkTimvQzfxJMRrQx5DviApbP=<a href="mailto:N3O1KRQ@mail.gmail.com">N3O1KRQ@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="iso-8859-1"<br>
><br>
> On Thu, Jun 2, 2011 at 12:38 AM, Maciej Stachowiak <<a href="mailto:mjs@apple.com">mjs@apple.com</a>> wrote:<br>
> ><br>
> > Looks to me like these fulfill the requirement of "do we ever use const<br>
> > pointers to these objects". So the next step is to fix up const member<br>
> > functions that inappropriately return non-const pointers to objects in the<br>
> > same tree (or that can otherwise get a back pointer). Make the functions<br>
> > non-const, then add const variants returning a const pointer if needed.<br>
> ><br>
> > I'm curious if there are any clients for const pointers to DOM nodes.<br>
> ><br>
><br>
> All functions passed to enclosingNodeOfType in htmlediting.cpp are such<br>
> clients:<br>
><br>
> Node* enclosingNodeOfType(const Position& p, bool (*nodeIsOfType)(const Node<br>
> *), EditingBoundaryCrossingRule rule)<br>
><br>
> It takes a boolean function that takes const pointer to a DOM node.  It is *<br>
> critical *that nodeIsOfType does not modify DOM because we use a raw pointer<br>
> to keep track of the current node when walking up the tree.<br>
><br>
> - Ryosuke<br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<a href="http://lists.webkit.org/pipermail/webkit-dev/attachments/20110602/fdfa9c1d/attachment-0001.html">http://lists.webkit.org/pipermail/webkit-dev/attachments/20110602/fdfa9c1d/attachment-0001.html</a>><br>

><br>
> ------------------------------<br>
><br>
> _______________________________________________<br>
> webkit-dev mailing list<br>
> <a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
> <a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
><br>
><br>
> End of webkit-dev Digest, Vol 73, Issue 2<br>
> *****************************************<br>
</p>