Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On 2015-07-14 9:59 AM, Kyle Huey wrote: On Tue, Jul 14, 2015 at 6:57 AM, Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhg...@gmail.com wrote: On 2015-07-13 3:07 PM, Jeff Gilbert wrote: On Sun, Jul 12, 2015 at 6:45 PM, Thomas Zimmermann tzimmerm...@mozilla.com mailto:tzimmerm...@mozilla.com wrote: Am 08.07.2015 um 16:36 schrieb smaug: Do you actually have any data how many % of Gecko devs would prefer not using aFoo? I strongly prefer 'aFoo' over 'foo' for the extra context that it gives to the variable. If we want to change anything we should rather introduce a separate prefix for output parameters. Which part of this extra context is useful? Repeating what Kats said elsewhere in the thread which seems to have been completely ignored in the pile of messages here: When debugging in a text based debugger such as gdb, sometimes you have a variable called aFoo which has the wrong value, and with the existing naming convention, you can quickly run up in the debugger to go to caller frames looking for the first time the argument is called something without an 'a' prefix, and then you look to see where the value was computed. If we remove this naming convention, you would have to do that work in every frame, which would make debugging the same scenario much more time consuming. Note that if you mostly use a graphical debugger such as Visual Studio, you may not rely on this because the debugger would show you more of the code in each frame, but I believe graphical debuggers are a niche among Mozilla developers. That assumes that the 'Foo' of aFoo is stable across function boundaries, which is not always the case. No, it doesn't. In the scenario above, all you're looking for is when a value was computed, so you can quickly see an aDuck, aQuack, aFoopyFoo and determine that the value was passed down from the caller, until you get to a call site which passes in something that doesn't start with an 'a'. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On 7/14/2015 1:39 AM, Thomas Zimmermann wrote: When writing code, I consider it good style to not write into anything that starts with an 'a' prefix, except result arguments. You should never write into something with an 'a' prefix except when you should, if you simplify it. I've actually avoided using the a prefix for outparams precisely because it feels more consistent to never assign to a variable with an a value (and also because it distinguishes between Foo *aInArray and Foo *outparam), yet I did see someone upthread praising that it helped you see which values were outparams. Makes the code cleaner, more readable, and often gives it a clear structure. When reading the code later on, it's easy to spot the parts of a the code that directly depend on external parameters by looking for 'a' and 'm' prefixes. This, I feel, is an aspiration which is not supported by any of the code I work on (which admittedly is heavily COMtaminated). Any intuition about a difference between aFoo and foo in terms of relies on arguments is bound to be wrong. Given that the aFoo rule is one of the least adhered-to portions of our style guide, and has been for as long as I've worked on Mozilla code; that the ancillary rule of don't assign to an argument has also been ignored on quite a few occasions; and that there hasn't been any real history of people complaining about the lack of adherence to this style guide point, I rather suspect that whatever people might say in how useful the 'a' prefix is, they get along quite fine without it. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tue, Jul 14, 2015 at 10:10 AM, Tom Tromey ttro...@mozilla.com wrote: That assumes that the 'Foo' of aFoo is stable across function boundaries, which is not always the case. Ehsan No, it doesn't. In the scenario above, all you're looking for is when Ehsan a value was computed, so you can quickly see an aDuck, aQuack, Ehsan aFoopyFoo and determine that the value was passed down from the Ehsan caller, until you get to a call site which passes in something that Ehsan doesn't start with an 'a'. It was mentioned elsewhere in this thread that some code assigns to arguments. In these cases going up to the point of origination may miss the spot that actually introduced the value. Admittedly not perfect, but as a first-order approximation: kats@kgupta-air mozilla-git$ find . -name *.cpp | xargs grep ^ *a[A-Z]\w* = | wc -l 5414 That's not a lot considering the size of the codebase. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On 7/8/2015 7:31 AM, Nathan Froyd wrote: If somebody is willing to do the formatting, I'm willing to do the review. I think the thread has reached the point of people repeating ad nauseum what was already said earlier in the thread, so it's time for a decision. Benjamin? Aww, I was avoiding getting into this thread. I personally have no strong preference, and our existing community is pretty deeply divided. I doubt we're going to come to consensus here, and this is a pretty tough decision to make on its own. I do believe that consistency trumps module/personal preference in terms of coding style. The argument I am most sympathetic to is that this convention is a barrier to new contributors. Making new contributors productive, both employees and volunteers, is a very good reason to choose one style over another. Given that premise, we shouldn't just change aArgument; we should adopt the Google C++ style guide wholesale: * names_with_underscores * members_with_trailing_ * no more ns prefix There is good research that underscore_names are more readable, and many of these will be more familiar to new contributors. Also we have a fair bit of shared code with Google. If there is a decision to be made here, I'd like to make this RFC: * switch our codebase wholesale to the Google C++ style guide With the following implementation plan: * For now, code should continue to be written in the current style with aFoo, mFoo, and camelCase. * get our code -Wshadow clean * Ask poiru to investigate auto-renaming of our variables including mFoo, aFoo, and camelCase to the google-standard local variable names. * Do not make any changes to the style guide or standard practice until we're comfortable that we can do automatic changes. * Make the automatic changes and change our style guide at roughly the same time. * Go back and deal with class names (nsFoo) as a separate/later pass. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On 2015-07-14 10:10 AM, Tom Tromey wrote: That assumes that the 'Foo' of aFoo is stable across function boundaries, which is not always the case. Ehsan No, it doesn't. In the scenario above, all you're looking for is when Ehsan a value was computed, so you can quickly see an aDuck, aQuack, Ehsan aFoopyFoo and determine that the value was passed down from the Ehsan caller, until you get to a call site which passes in something that Ehsan doesn't start with an 'a'. It was mentioned elsewhere in this thread that some code assigns to arguments. In these cases going up to the point of origination may miss the spot that actually introduced the value. That's true. In practice though, I use this technique all the time and I can't remember the last time I was bit by someone assigning to an argument when chasing a bad value in the debugger. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On 2015-07-13 3:07 PM, Jeff Gilbert wrote: On Sun, Jul 12, 2015 at 6:45 PM, Thomas Zimmermann tzimmerm...@mozilla.com wrote: Am 08.07.2015 um 16:36 schrieb smaug: Do you actually have any data how many % of Gecko devs would prefer not using aFoo? I strongly prefer 'aFoo' over 'foo' for the extra context that it gives to the variable. If we want to change anything we should rather introduce a separate prefix for output parameters. Which part of this extra context is useful? Repeating what Kats said elsewhere in the thread which seems to have been completely ignored in the pile of messages here: When debugging in a text based debugger such as gdb, sometimes you have a variable called aFoo which has the wrong value, and with the existing naming convention, you can quickly run up in the debugger to go to caller frames looking for the first time the argument is called something without an 'a' prefix, and then you look to see where the value was computed. If we remove this naming convention, you would have to do that work in every frame, which would make debugging the same scenario much more time consuming. Note that if you mostly use a graphical debugger such as Visual Studio, you may not rely on this because the debugger would show you more of the code in each frame, but I believe graphical debuggers are a niche among Mozilla developers. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tue, Jul 14, 2015 at 6:57 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-07-13 3:07 PM, Jeff Gilbert wrote: On Sun, Jul 12, 2015 at 6:45 PM, Thomas Zimmermann tzimmerm...@mozilla.com wrote: Am 08.07.2015 um 16:36 schrieb smaug: Do you actually have any data how many % of Gecko devs would prefer not using aFoo? I strongly prefer 'aFoo' over 'foo' for the extra context that it gives to the variable. If we want to change anything we should rather introduce a separate prefix for output parameters. Which part of this extra context is useful? Repeating what Kats said elsewhere in the thread which seems to have been completely ignored in the pile of messages here: When debugging in a text based debugger such as gdb, sometimes you have a variable called aFoo which has the wrong value, and with the existing naming convention, you can quickly run up in the debugger to go to caller frames looking for the first time the argument is called something without an 'a' prefix, and then you look to see where the value was computed. If we remove this naming convention, you would have to do that work in every frame, which would make debugging the same scenario much more time consuming. Note that if you mostly use a graphical debugger such as Visual Studio, you may not rely on this because the debugger would show you more of the code in each frame, but I believe graphical debuggers are a niche among Mozilla developers. That assumes that the 'Foo' of aFoo is stable across function boundaries, which is not always the case. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
Hi Am 14.07.2015 um 16:19 schrieb Joshua Cranmer : On 7/14/2015 1:39 AM, Thomas Zimmermann wrote: When writing code, I consider it good style to not write into anything that starts with an 'a' prefix, except result arguments. You should never write into something with an 'a' prefix except when you should, if you simplify it. I've actually avoided using the a prefix for outparams precisely because it feels more consistent to never assign to a variable with an a value (and also because it distinguishes between Foo *aInArray and Foo *outparam), yet I did see someone upthread praising that it helped you see which values were outparams. As I said above, I'd support introducing a separate prefix for output parameters. And consequently enforcing the no-a-writes policy in reviews. Makes the code cleaner, more readable, and often gives it a clear structure. When reading the code later on, it's easy to spot the parts of a the code that directly depend on external parameters by looking for 'a' and 'm' prefixes. This, I feel, is an aspiration which is not supported by any of the code I work on (which admittedly is heavily COMtaminated). Any intuition about a difference between aFoo and foo in terms of relies on arguments is bound to be wrong. I agree in general, but there are a number of conventions for special symbols: prefixes, all-capitals, start-with-capital, etc. Each helps to structure the code and make it more readable. That doesn't mean that the other symbols are unimportant. I never claimed that it's possible to understand code without actually reading it. Given that the aFoo rule is one of the least adhered-to portions of our style guide, and has been for as long as I've worked on Mozilla code; that the ancillary rule of don't assign to an argument has also been ignored on quite a few occasions; and that there hasn't been any real history of people complaining about the lack of adherence to this style guide point, I rather suspect that whatever people might say in how useful the 'a' prefix is, they get along quite fine without it. In such cases, I always wonder why the coding style is incorrect. The discussion has a number of good points in favor of using 'a', but I missed convincing arguments in favor of not using 'a'. Are there any? I don't consider I don't get what 'a' is good for a convincing argument. Best regards Thomas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On 7/14/2015 10:23 AM, Benjamin Smedberg wrote: Given that premise, we shouldn't just change aArgument; we should adopt the Google C++ style guide wholesale: * names_with_underscores The biggest problem here is that WebIDL and XPIDL codegen are heavily geared towards camelCase names, as the IDL convention is camelCase. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
May I request that the major parts of this not happen until we have a blame that can see through such changes. Last I checked, gps had some ideas in that space but lacked time to implement. On Wed, Jul 15, 2015, at 03:23 AM, Benjamin Smedberg wrote: On 7/8/2015 7:31 AM, Nathan Froyd wrote: If somebody is willing to do the formatting, I'm willing to do the review. I think the thread has reached the point of people repeating ad nauseum what was already said earlier in the thread, so it's time for a decision. Benjamin? Aww, I was avoiding getting into this thread. I personally have no strong preference, and our existing community is pretty deeply divided. I doubt we're going to come to consensus here, and this is a pretty tough decision to make on its own. I do believe that consistency trumps module/personal preference in terms of coding style. The argument I am most sympathetic to is that this convention is a barrier to new contributors. Making new contributors productive, both employees and volunteers, is a very good reason to choose one style over another. Given that premise, we shouldn't just change aArgument; we should adopt the Google C++ style guide wholesale: * names_with_underscores * members_with_trailing_ * no more ns prefix There is good research that underscore_names are more readable, and many of these will be more familiar to new contributors. Also we have a fair bit of shared code with Google. If there is a decision to be made here, I'd like to make this RFC: * switch our codebase wholesale to the Google C++ style guide With the following implementation plan: * For now, code should continue to be written in the current style with aFoo, mFoo, and camelCase. * get our code -Wshadow clean * Ask poiru to investigate auto-renaming of our variables including mFoo, aFoo, and camelCase to the google-standard local variable names. * Do not make any changes to the style guide or standard practice until we're comfortable that we can do automatic changes. * Make the automatic changes and change our style guide at roughly the same time. * Go back and deal with class names (nsFoo) as a separate/later pass. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On Jul 14, 2015, at 8:23 AM, Benjamin Smedberg benja...@smedbergs.us wrote: * no more ns prefix Are people still creating new classes with an ’ns’ prefix? Surely this is something we can drop right away, at least for new code. Much of the codebase already does not use this style. We have namespaces now, after all. - Seth ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
(and 600+ plus of those are from my objdirs, actually). Here it is broken down by dir: kats@kgupta-air mozilla-git$ find . -type d -maxdepth 1 -mindepth 1 | grep -v .git | while read dir; do pushd $dir /dev/null; find . -name *.cpp | xargs grep ^ *a[A-Z]\w* = | wc -l | xargs echo $dir; popd /dev/null; done ./accessible 10 ./addon-sdk 0 ./b2g 0 ./browser 0 ./build 0 ./caps 5 ./chrome 4 ./config 0 ./db 0 ./docshell 19 ./dom 1739 ./editor 95 ./embedding 12 ./extensions 20 ./gfx 229 ./hal 2 ./image 33 ./intl 55 ./ipc 23 ./js 1 ./layout 1063 ./media 15 ./memory 0 ./mfbt 0 ./mobile 0 ./modules 6 ./mozglue 2 ./netwerk 124 ./nsprpub 0 ./obj-b2g-desktop 320 ./obj-host 329 ./other-licenses 2 ./parser 80 ./probes 0 ./python 0 ./rdf 3 ./security 38 ./services 0 ./startupcache 0 ./storage 2 ./testing 0 ./toolkit 68 ./tools 3 ./uriloader 43 ./view 8 ./webapprt 0 ./widget 876 ./xpcom 177 ./xpfe 8 ./xulrunner 0 On Tue, Jul 14, 2015 at 10:30 AM, L. David Baron dba...@dbaron.org wrote: On Tuesday 2015-07-14 10:27 -0400, Kartikaya Gupta wrote: Admittedly not perfect, but as a first-order approximation: kats@kgupta-air mozilla-git$ find . -name *.cpp | xargs grep ^ *a[A-Z]\w* = | wc -l 5414 That's not a lot considering the size of the codebase. And a decent portion of those are assigning to out-params that are references rather than pointers. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tuesday 2015-07-14 10:27 -0400, Kartikaya Gupta wrote: Admittedly not perfect, but as a first-order approximation: kats@kgupta-air mozilla-git$ find . -name *.cpp | xargs grep ^ *a[A-Z]\w* = | wc -l 5414 That's not a lot considering the size of the codebase. And a decent portion of those are assigning to out-params that are references rather than pointers. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
Hi Am 13.07.2015 um 21:07 schrieb Jeff Gilbert: On Sun, Jul 12, 2015 at 6:45 PM, Thomas Zimmermann tzimmerm...@mozilla.com mailto:tzimmerm...@mozilla.com wrote: Am 08.07.2015 um 16:36 schrieb smaug: Do you actually have any data how many % of Gecko devs would prefer not using aFoo? I strongly prefer 'aFoo' over 'foo' for the extra context that it gives to the variable. If we want to change anything we should rather introduce a separate prefix for output parameters. Which part of this extra context is useful? When writing code, I consider it good style to not write into anything that starts with an 'a' prefix, except result arguments. Makes the code cleaner, more readable, and often gives it a clear structure. When reading the code later on, it's easy to spot the parts of a the code that directly depend on external parameters by looking for 'a' and 'm' prefixes. Everything else is helper code or for temporary results. Longer functions that have 'a's and 'm's all over the place are good candidates for refactoring. Best regards Thomas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
That assumes that the 'Foo' of aFoo is stable across function boundaries, which is not always the case. Ehsan No, it doesn't. In the scenario above, all you're looking for is when Ehsan a value was computed, so you can quickly see an aDuck, aQuack, Ehsan aFoopyFoo and determine that the value was passed down from the Ehsan caller, until you get to a call site which passes in something that Ehsan doesn't start with an 'a'. It was mentioned elsewhere in this thread that some code assigns to arguments. In these cases going up to the point of origination may miss the spot that actually introduced the value. Tom ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On Tue, Jul 14, 2015 at 9:06 AM, David Major dma...@mozilla.com wrote: May I request that the major parts of this not happen until we have a blame that can see through such changes. Last I checked, gps had some ideas in that space but lacked time to implement. I spoke to a Mercurial maintainer about some of my ideas and the feature would be welcome upstream. However, there isn't enough time to land for Mercurial 3.5 (code freeze this week), so we'd have to wait until Mercurial 3.6 (November 1 release date) at the earliest. That being said, every other organizations in the world is using the same or similar tools and is faced with similar challenges. Lack of a commit-skipping feature doesn't hinder other organizations from performing major refactorings. So while I'd love to make the tools better, I don't think waiting on the tools should be a blocker to mass reformatting the tree. While I'm here, if anyone has suggestions for quick fixes to https://hg.mozilla.org/'s HTML output, those are relatively easy to make. Please file bugs against Developer Services :: hg.mozilla.org if you have ideas! And, if you want to hack on improvements yourself, https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmo/contributing.html#hacking-the-theming tells you how. I reckon we could come up with enough small changes to hold us over until commit skipping in blame is implemented. On Wed, Jul 15, 2015, at 03:23 AM, Benjamin Smedberg wrote: On 7/8/2015 7:31 AM, Nathan Froyd wrote: If somebody is willing to do the formatting, I'm willing to do the review. I think the thread has reached the point of people repeating ad nauseum what was already said earlier in the thread, so it's time for a decision. Benjamin? Aww, I was avoiding getting into this thread. I personally have no strong preference, and our existing community is pretty deeply divided. I doubt we're going to come to consensus here, and this is a pretty tough decision to make on its own. I do believe that consistency trumps module/personal preference in terms of coding style. The argument I am most sympathetic to is that this convention is a barrier to new contributors. Making new contributors productive, both employees and volunteers, is a very good reason to choose one style over another. Given that premise, we shouldn't just change aArgument; we should adopt the Google C++ style guide wholesale: * names_with_underscores * members_with_trailing_ * no more ns prefix There is good research that underscore_names are more readable, and many of these will be more familiar to new contributors. Also we have a fair bit of shared code with Google. If there is a decision to be made here, I'd like to make this RFC: * switch our codebase wholesale to the Google C++ style guide With the following implementation plan: * For now, code should continue to be written in the current style with aFoo, mFoo, and camelCase. * get our code -Wshadow clean * Ask poiru to investigate auto-renaming of our variables including mFoo, aFoo, and camelCase to the google-standard local variable names. * Do not make any changes to the style guide or standard practice until we're comfortable that we can do automatic changes. * Make the automatic changes and change our style guide at roughly the same time. * Go back and deal with class names (nsFoo) as a separate/later pass. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On Tue, Jul 14, 2015 at 10:06 AM, Gregory Szorc g...@mozilla.com wrote: That being said, every other organizations in the world is using the same or similar tools and is faced with similar challenges. Lack of a commit-skipping feature doesn't hinder other organizations from performing major refactorings. So while I'd love to make the tools better, I don't think waiting on the tools should be a blocker to mass reformatting the tree. This. If blame is the only victim, and a temporary one, then that's a pretty small price to pay. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
Tom Tromey writes: It was mentioned elsewhere in this thread that some code assigns to arguments. The style guide should clarify that parameters named aFoo should not be assigned to. Otherwise that defeats the purpose. Non-const references are the exception. If these are really needed, then something in the name would be helpful. Something specific to non-const references would be nice, but 'a' is better than nothing. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On Wed, Jul 15, 2015 at 3:40 AM, Joshua Cranmer pidgeo...@gmail.com wrote: The biggest problem here is that WebIDL and XPIDL codegen are heavily geared towards camelCase names, as the IDL convention is camelCase. C++ names matching WebIDL (or spec names in general) has value. We've gotten quite close to that over the last several years. Maybe renaming tools could understand and enforce the relationship with WebIDL, but is _ identifiers everywhere except where we're matching specs the optimal long-term state? Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship Service Worker Notification API
Hello, Target release: Firefox 42 Implementation and shipping bug: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=1114554 Specification: https://notifications.spec.whatwg.org/#service-worker-api This is a follow up to the Notification API on worker support that landed in Firefox 41 [1]. These patches implement support for the `showNotification()` and `getNotifications()` methods on ServiceWorkerRegistration. The `Notification` constructor is available on ServiceWorkers but throws an error if actually used. Potential for abuse? This API allows service workers to show notifications to the user. This can happen even when a tab/window for the origin is not open in the browser. Service Workers can only run when the UA decides to run them and ideally only for a short time. If we notice abuse, we could restrict the ability to show notifications only to certain events (like push) and forbid them in others (like fetch events which occur several orders of magnitude more often), but we do not do that right now. Platforms: Available on all platforms. But Firefox for Android has limitations on its notification subsystem that prevents this from working. Support in other engines: Blink - shipped in Chrome 42/Opera 29- https://groups.google.com/a/chromium.org/d/topic/blink-dev/Cr7_GRSd2zM/discussion Webkit - not supported Edge/Trident: not supported Developer documentation: https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerRegistration/showNotification [1] https://groups.google.com/forum/#!topic/mozilla.dev.platform/CsM4I2Y9tS0 Best, Nikhil ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement W3C Manifest for web application
(Please kindly cc me if you want my attention in this thread. I don't subscribe to mailing lists.) On Friday, April 18, 2014 at 7:22:56 AM UTC+10, Marcos Caceres wrote: Summary: JSON-based manifest, which provides developers with a centralized place to put metadata associated with a web application. This includes, but is not limited to, the web application's name, links to icons, as well as the preferred URL to open when the user launches the web application. The manifest also allows developers to declare a default orientation for their web application, as well as how the application is to be displayed by the user agent (e.g., in fullscreen). Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=997779 Link: http://w3c.github.io/manifest/ Platform coverage: All. Estimated or target release: Q3 or Q4, 2014 A few people have reached out to me with concerns about implementing web manifest in Gecko and have asked me to restart this thread (given that no one objected the first time around). There are concerns about the utility of Web manifests, the overall vision of appifying the Web, and their purpose given that the essentially replicate functionality in well-established and widely used meta elements. Some of the things raised: * It's not clear what problems manifest solves: do we really want to replicate native app installation behavior on the Web? We don't have a good history of making this work in various products. * Extra HTTP request could yield a performance penalty (even if deprioritized)... though probably not a concern in a HTTP2 world. * Can't we just use meta tags (application-name, etc.)? * App-scope is as bad, or worst, than scope in service workers (i.e., you only get one directory in a domain, or the whole domain). * How would Desktop firefox make use of display modes? (i.e., how would they work with tab browsing) Discuss! But please cc me, or else I might not read it :) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should the entire JS structure be Object.freeze()'d if it's exposed through a read only property?
On 7/13/15 2:40 AM, Tim Guan-tin Chien wrote: In that case, the right question to ask would be (A) should DOMApplication#manifest be a recursive frozen JS structure Is it a plain vanilla object with nothing hanging off it that has getter/setters? If so, that would not be unreasonable. and maybe (B) should WebIDL binding provide an keyword like DeepFrozen that could recursive freeze the exposed structure. We could do that, probably. It's not trivial, but is doable. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement W3C Manifest for web application
I'd rather see us solve the individual problems that manifests aim to solve using some combination of meta tags, link relations and plain-ol' DOM/JS APIs. The manifest is no better than the former two. It already replicates features that these provide when it comes to icons. In particular, the idea of identifying an app in the sense that app-scope implies is a poor fit for the web. There are likely some valuable use cases that can be extracted from this: for instance, I can see the benefit in being able to bookmark gmail without identifying whatever message or folder is current visible at the time; or a new site without the title forever reflecting the headline of the day. But again, those are things that can be done without manifests. On Tue, Jul 14, 2015 at 3:00 PM, mar...@marcosc.com wrote: (Please kindly cc me if you want my attention in this thread. I don't subscribe to mailing lists.) On Friday, April 18, 2014 at 7:22:56 AM UTC+10, Marcos Caceres wrote: Summary: JSON-based manifest, which provides developers with a centralized place to put metadata associated with a web application. This includes, but is not limited to, the web application's name, links to icons, as well as the preferred URL to open when the user launches the web application. The manifest also allows developers to declare a default orientation for their web application, as well as how the application is to be displayed by the user agent (e.g., in fullscreen). Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=997779 Link: http://w3c.github.io/manifest/ Platform coverage: All. Estimated or target release: Q3 or Q4, 2014 A few people have reached out to me with concerns about implementing web manifest in Gecko and have asked me to restart this thread (given that no one objected the first time around). There are concerns about the utility of Web manifests, the overall vision of appifying the Web, and their purpose given that the essentially replicate functionality in well-established and widely used meta elements. Some of the things raised: * It's not clear what problems manifest solves: do we really want to replicate native app installation behavior on the Web? We don't have a good history of making this work in various products. * Extra HTTP request could yield a performance penalty (even if deprioritized)... though probably not a concern in a HTTP2 world. * Can't we just use meta tags (application-name, etc.)? * App-scope is as bad, or worst, than scope in service workers (i.e., you only get one directory in a domain, or the whole domain). * How would Desktop firefox make use of display modes? (i.e., how would they work with tab browsing) Discuss! But please cc me, or else I might not read it :) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On 14 July 2015 at 08:23, Benjamin Smedberg benja...@smedbergs.us wrote: The argument I am most sympathetic to is that this convention is a barrier to new contributors. Making new contributors productive, both employees and volunteers, is a very good reason to choose one style over another. The C++ world is a huge mishmash of different styles. I don't think Google style is necessarily any better than our style. And, to be fair, our style is actually fairly close to Google style with a few exceptions like variable naming. The real issue is that we have vastly different code styles throughout our codebase. We use 2 spaces for indentation in some modules and 4 spaces in others. Some places defiantly use tabs and a few files have compromised on 3 space indentation (eww!). Some modules place the pointer adjacent to the type, others put it beside the name. Some modules always brace control statements, others do not. It's not our style that is the problem for new (and old!) contributors; it's the huge inconsistency. I'm making Clang-Format compatible with our style over in bug 961541. Once Clang-Format is good enough, I will rewrite the entire tree on a directory-by-directory basis. Given that premise, we shouldn't just change aArgument; we should adopt the Google C++ style guide wholesale: * names_with_underscores * members_with_trailing_ If we were to do this, some names would become shorter and other longer. That might break the 80 column limit in places and break alignment in others. (Also keep in mind that Google style mandates `foo_bar()` for getters and `set_foo_bar()` for setters.) This is a general problem with rewriting. In order to perform them effectively, we need to have a consistent style and tool to automatically reformat diffs to that style. I personally don't think switching to Google style naming is worth it. It would require far more changes than just sticking with either aFooBar or fooBar for no apparent benefit. Cheers, Biru ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Wed, Jul 15, 2015 at 2:55 AM, Thomas Zimmermann tzimmerm...@mozilla.com wrote: The discussion has a number of good points in favor of using 'a', but I missed convincing arguments in favor of not using 'a'. Are there any? I don't consider I don't get what 'a' is good for a convincing argument. It increases the overhead of extracting part of a large function into a helper function, because typically some local variables become parameters of the helper function, so they have to be renamed. Admittedly, C++ already inhibits this refactoring by (usually) requiring helper method declarations to be repeated in the class declaration ... which is one of the things I most dislike about C++. But every increase in overhead reduces the likelihood that the refactoring will be done when it should. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
I'm not wild about this idea. Switching styles entirely would be several times more churn and work than just making our existing codebase conform to our existing style guide. Consistency with Google's style might be a nice bonus, and there might be subjective arguments for one or the other, but none of that seems worth the churn and disruption this would cause, IMO. On Tue, Jul 14, 2015 at 11:23 AM, Benjamin Smedberg benja...@smedbergs.us wrote: On 7/8/2015 7:31 AM, Nathan Froyd wrote: If somebody is willing to do the formatting, I'm willing to do the review. I think the thread has reached the point of people repeating ad nauseum what was already said earlier in the thread, so it's time for a decision. Benjamin? Aww, I was avoiding getting into this thread. I personally have no strong preference, and our existing community is pretty deeply divided. I doubt we're going to come to consensus here, and this is a pretty tough decision to make on its own. I do believe that consistency trumps module/personal preference in terms of coding style. The argument I am most sympathetic to is that this convention is a barrier to new contributors. Making new contributors productive, both employees and volunteers, is a very good reason to choose one style over another. Given that premise, we shouldn't just change aArgument; we should adopt the Google C++ style guide wholesale: * names_with_underscores * members_with_trailing_ * no more ns prefix There is good research that underscore_names are more readable, and many of these will be more familiar to new contributors. Also we have a fair bit of shared code with Google. If there is a decision to be made here, I'd like to make this RFC: * switch our codebase wholesale to the Google C++ style guide With the following implementation plan: * For now, code should continue to be written in the current style with aFoo, mFoo, and camelCase. * get our code -Wshadow clean * Ask poiru to investigate auto-renaming of our variables including mFoo, aFoo, and camelCase to the google-standard local variable names. * Do not make any changes to the style guide or standard practice until we're comfortable that we can do automatic changes. * Make the automatic changes and change our style guide at roughly the same time. * Go back and deal with class names (nsFoo) as a separate/later pass. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement W3C Manifest for web application
On Wed, Jul 15, 2015 at 12:00 AM, mar...@marcosc.com wrote: * It's not clear what problems manifest solves This is by far the biggest problem. I think we ended up with manifests because packages have manifests and iOS/Android use packages for applications, but none of that translates well to the web. * Extra HTTP request could yield a performance penalty (even if deprioritized)... though probably not a concern in a HTTP2 world. It's still a concern. You'll still need to duplicate all the metadata that the client needs immediately in the HTML. One reason that was mentioned in favor of manifests was don't repeat yourself. The way the web has dealt with that for two decades is server-side templating. If this was really the core concern we should figure out client-side templating for HTML, since this does not just affect document metadata. I agree with Martin that focusing on concrete problems to solve is a more worthwhile endeavor. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On Tue, Jul 14, 2015 at 8:06 PM, Bobby Holley bobbyhol...@gmail.com wrote: I'm not wild about this idea. It's such a boil-the-ocean solution I honestly thought bsmedberg was joking at first... Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On Tue, Jul 14, 2015 at 8:23 AM, Benjamin Smedberg benja...@smedbergs.us wrote: On 7/8/2015 7:31 AM, Nathan Froyd wrote: If somebody is willing to do the formatting, I'm willing to do the review. I think the thread has reached the point of people repeating ad nauseum what was already said earlier in the thread, so it's time for a decision. Benjamin? Aww, I was avoiding getting into this thread. I personally have no strong preference, and our existing community is pretty deeply divided. I doubt we're going to come to consensus here, and this is a pretty tough decision to make on its own. I do believe that consistency trumps module/personal preference in terms of coding style. The argument I am most sympathetic to is that this convention is a barrier to new contributors. Making new contributors productive, both employees and volunteers, is a very good reason to choose one style over another. Given that premise, we shouldn't just change aArgument; we should adopt the Google C++ style guide wholesale: * names_with_underscores * members_with_trailing_ * no more ns prefix There is good research that underscore_names are more readable, and many of these will be more familiar to new contributors. Also we have a fair bit of shared code with Google. If there is a decision to be made here, I'd like to make this RFC: * switch our codebase wholesale to the Google C++ style guide With the following implementation plan: * For now, code should continue to be written in the current style with aFoo, mFoo, and camelCase. * get our code -Wshadow clean * Ask poiru to investigate auto-renaming of our variables including mFoo, aFoo, and camelCase to the google-standard local variable names. * Do not make any changes to the style guide or standard practice until we're comfortable that we can do automatic changes. * Make the automatic changes and change our style guide at roughly the same time. * Go back and deal with class names (nsFoo) as a separate/later pass. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform FWIW, I think the Google C++ style is terrible, but if it gets us to a point where we can run clang-format as part of make check and never worry about style again I am all for it. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On 07/14/2015 08:11 PM, Martin Thomson wrote: On Tue, Jul 14, 2015 at 10:06 AM, Gregory Szorc g...@mozilla.com wrote: That being said, every other organizations in the world is using the same or similar tools and is faced with similar challenges. Lack of a commit-skipping feature doesn't hinder other organizations from performing major refactorings. So while I'd love to make the tools better, I don't think waiting on the tools should be a blocker to mass reformatting the tree. This. If blame is the only victim, and a temporary one, then that's a pretty small price to pay. Couple of work days per year for certain devs? Perhaps it is a small price. Also, if we just stick with the current coding style, large parts of Gecko doesn't need to be refactored to new style. About using Google coding style, there isn't any evidence it would make new contributors more productive, and it might make old contributors less productive at least for some time. But whatever we change, if any - since the current coding style is rather sane for C++ - consistency is what I care about most. It is mystery to me why we've still written new code not using the coding style we have had for ages. I guess that is where we really need tools, enforce some style. -Olli ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
