Re: On the usefulness of style guides (Was: style guide proposal)
Brian Smith wrote: In PSM, we created some scoped pointer wrapper types around NSS data structures (ScopedNSSTypes.h), which are based on the MFBT scoped pointers. And, consequently, PSM has standardized on MFBT smart pointers throughout the module (there should be nsRefPtr in PSM, only RefPtr, for example). Yet, most code in Gecko is based on the nsCOMPtr-like smart pointers (nsAutoPtr, nsRefPtr). I don't know how big of a deal this is, but this is the type of thing that would need to be resolved to have a consistent style throughout Gecko. I thought that it was pretty clear which smart pointer to use: nsCOMPtr - interfaces nsRefPtr - concrete types that inherit from nsISupports RefPtr - everything else (i.e. no QueryInterface) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On the usefulness of style guides (Was: style guide proposal)
Ehsan Akhgari wrote: To be very specific, here's a number of examples of things which our code base doesn't agree on: 1. Line endings Which is probably the easiest and least controversial thing to check for. I blame whoever it was who decided to include a vim that defaults to DOS line endings in mozillabuild. (And I don't just mean default as in the default setting for line endings is DOS; the warning about non-standard line endings thinks that DOS line endings are standard and that can't be changed.) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On the usefulness of style guides (Was: style guide proposal)
On 12/19/2013 09:57 AM, Till Schneidereit wrote: I think we should do more than encourage: we should back out for all style guide violations. Period. We could even enforce that during upload to a review tool, perhaps. Is this a guide or a rule? From my point of view, this is a guide, which is here to say: “This is what is commonly accepted”. The root of the problem is that some people might make changes which are unreadable. And having a convention to define a common grammar is good for readability. This is what a guide is all about, a grammar. Now, a few times, breaking the rule to introduce idioms which are locally acceptable *for the sake of readability*, and might not necessary fit in the style guide. Would a grammar checker accept all the ASCII arts in comments? This is my last words on this topics, too much bytes have been wasted on this topic already. -- Nicolas B. Pierron ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On the usefulness of style guides (Was: style guide proposal)
On 12/20/2013 10:55 AM, Neil wrote: Brian Smith wrote: In PSM, we created some scoped pointer wrapper types around NSS data structures (ScopedNSSTypes.h), which are based on the MFBT scoped pointers. And, consequently, PSM has standardized on MFBT smart pointers throughout the module (there should be nsRefPtr in PSM, only RefPtr, for example). Yet, most code in Gecko is based on the nsCOMPtr-like smart pointers (nsAutoPtr, nsRefPtr). I don't know how big of a deal this is, but this is the type of thing that would need to be resolved to have a consistent style throughout Gecko. I thought that it was pretty clear which smart pointer to use: nsCOMPtr - interfaces nsRefPtr - concrete types that inherit from nsISupports RefPtr - everything else (i.e. no QueryInterface) That makes it quite clear it isn't clear: nsCOMPtr - interfaces nsRefPtr - concrete types RefPtr - code imported from WebKit HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: nsIDownloadManager replaced by Downloads.jsm
On Saturday, August 3, 2013 7:21:57 AM UTC-5, Paolo Amadini wrote: Hello, I am nobody. But, I want file timestamps to be preserved when I download files. I guess I will use wget until this gets fixed. Now I have no reason to use Firefox. I was using this until todays upgrade to FF 26: Preserve Download Modification Timestamp addon I do hope someone is still working on fixing this. https://bugzilla.mozilla.org/show_bug.cgi?id=918188 Thanks, Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On the usefulness of style guides (Was: style guide proposal)
On 12/19/13, 6:50 PM, Bobby Holley wrote: And that should include accepting patches to fix the style across their module. ;-) FWIW I'm totally fine with mass-conversions if people want to do them. Any mass conversions of code style should coincide with the next ESR release. Imagine the protracted pain if every patch uplifted to ESR has a merge conflict due to minor style changes. The current ESR is Firefox 24, which will be supported until October 2014. The next ESR is Firefox 31, which hits mozilla-central in March 2014 and will be supported into 2015. https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal https://wiki.mozilla.org/RapidRelease/Calendar chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On the usefulness of style guides (Was: style guide proposal)
Ms2ger wrote: On 12/20/2013 10:55 AM, Neil wrote: I thought that it was pretty clear which smart pointer to use: That makes it quite clear it isn't clear: nsCOMPtr - interfaces nsRefPtr - concrete types RefPtr - code imported from WebKit HTH MXR claims we have three types named RefPtr. One is indeed used by some yarr code imported from WebKit. There's one in cairo. And then there's one in MFBT. What I find confusing, given the number of uses of RefPtr, is that there appear to be very few includes of RefPtr.h itself, although MacIOSurface.h manages to include it twice yet doesn't even use RefPtr! -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
