Re: mozilla::TemporaryRef is gone; please use already_AddRefed
On Tue, Jul 7, 2015 at 6:10 PM, Michael Layzell mich...@thelayzells.com wrote: No, I never checked if it happens on an optimized build, but as C++ follows an as-if principal, which means that code has to execute as if those temporaries had been created. Unfortunately, AddRef and Release are virtual, which, I'm pretty sure, means that the compiler can't optimize them out as they may have arbitrary side effects :(. So the temporaries are probably eliminated, but the calls to AddRef and Release are probably not. I could be wrong on this though. This is true except in special cases where copy elision is allowed, in which case the temporary may be removed entirely, with its constructor and destructor. According to 12.8.32 of http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2011/n3242.pdf, one of those cases is when a temporary class object that has not been bound to a reference (12.2) would be copied/moved to a class object with the same cv-unqualified type, the copy/move operation can be omitted by constructing the temporary object directly into the target of the omitted copy/move I'm not an expert in C++-ese, but this looks like exactly that, so compilers should be allowed to remove the AddRef/Release. Whether they do or not is a separate question -- I'd hope so, in such a simple-looking case. ___ 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 8, 2015 at 6:52 AM, Gabor Krizsanits gkrizsan...@mozilla.com wrote: On Wed, Jul 8, 2015 at 1:05 AM, Bobby Holley bobbyhol...@gmail.com wrote: The priority is to automatically rewrite our source with a unified style. foo - aFoo is reasonably safe, whereas aFoo-foo is not, at least with the current tools. So we either need to combine the rewrite tools with static analysis, or just go with aFoo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform +1 for consistency. Any volunteers who is willing to get rid of aFoo EVERYWHERE and someone else who is willing to review that work? If not then we should do it the other way around. 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? -Nathan ___ 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 8, 2015 at 1:05 AM, Bobby Holley bobbyhol...@gmail.com wrote: On Tue, Jul 7, 2015 at 3:59 PM, Eric Rahm er...@mozilla.com wrote: I'm not a huge fan of the 'aFoo' style, but I am a huge fan of consistency. So if we want to change the style guide we should update our codebase, and I don't think we can reasonably do that automatically without introducing shadowing issues. This a great point, and perhaps the most useful one to be raised in this thread. The priority is to automatically rewrite our source with a unified style. foo - aFoo is reasonably safe, whereas aFoo-foo is not, at least with the current tools. So we either need to combine the rewrite tools with static analysis, or just go with aFoo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform +1 for consistency. Any volunteers who is willing to get rid of aFoo EVERYWHERE and someone else who is willing to review that work? If not then we should do it the other way around. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: LGPL external library support in gecko
On 08/07/15 07:17, Kyle Machulis wrote: If you've had requirements for an external library with an LGPL license, we now have a place to put them. There's still some odd things that you have to do with symbol visibility to get this to work (feel free to ping me or hit #build on IRC if you have issues), and obviously licenses will still need to be vetted by gerv and added to the about:license page. This should make things easier to integrate overall though. This is great, Kyle - thanks :-) Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: LGPL external library support in gecko
On 2015-07-08 2:17 AM, Kyle Machulis wrote: If you've had requirements for an external library with an LGPL license, we now have a place to put them. This is fully awesome. - mhoye ___ 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 07/08/2015 04:05 AM, Milan Sreckovic wrote: Jeff encouraged me to add more things to this thread, so I’m blaming him. So, some random thoughts. After getting paid to write code for 20+ years and then showing up at Mozilla, and seeing the a prefix, I thought “this is brilliant, how come we didn’t think of doing that before?!”, as a reasonable balance between nothing and the insanity of the full Hungarian. I find a prefix useful when I’m writing code and when I’m reading it. I have no trouble reading the code that isn’t using this convention. I don’t think I ran into a situation where only some of the arguments in the function were using the prefix (and some were not), but I can imagine that being the only situation where I’d argue that it’s confusing. In other words, as weird as it may sound, I find the prefix improving the readability, but the lack of it not hindering it. And it makes no difference to me when I’m reviewing code, which is a couple of orders of magnitude fewer times than for most people on this thread. If I was writing a new file from scratch, I’d use this convention. If I was in a file that wasn’t using it, it wouldn’t bother me. I think it would be a bad idea to force this consistency on the whole codebase (e.g., either clear it out, or put it everywhere), as I don’t think it would actually solve anything. The “consistent is good” can be taken too far, and I think this would be taking it too far. I honestly think the best thing to do here is nothing - remove it from the style guide if we don’t want to enforce it, but don’t stop me from using it. Removing it from the coding style, yet allowing it to be used would be the worst case. Whatever we do, better do it consistently. Blame Jeff for the above. — - Milan On Jul 7, 2015, at 20:41 , Karl Tomlinson mozn...@karlt.net wrote: Jeff Gilbert writes: It can be a burden on the hundreds of devs who have to read and understand the code in order to write more code. Some people find the prefix helps readability, because it makes extra information immediately available in the code being examined, while you are indicating that this is a significant burden on readability. Can you explain why the extra letter is a significant burden? If the 'a' prefix is a burden then the 'm' prefix must be also, and so we should be using this-member instead of mMember. The opinions of a few over-harried reviewers should not hold undue sway over the many many devs writing code. unless people want code to be reviewed. ___ 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: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
Do you actually have any data how many % of Gecko devs would prefer not using aFoo? I mean it makes no sense to change to foo, if most of the devs prefer aFoo. Similarly I would stop objecting the change if majority of the devs say yes, please change this coding style which Mozilla has had forever[1]. (it might mean me doing reviews a bit slower, which tends to lead fewer review requests, which might not be such a bad thing ;) ) Right now it feels like there are couple of devs in favor of aFoo, and couple of devs in favor of foo, and the rest haven't said anything. -Olli [1] Note, the coding style has been there for a long time, but not followed in all the modules for some reason. On 07/07/2015 06:12 AM, Jeff Gilbert wrote: I propose that we stop recommending the universal use of an 'a' prefix for arguments to functions in C and C++. If the prefix helps with disambiguation, that's fine. However, use of this prefix should not be prescribed in general. `aFoo` does not provide any additional safety that I know of.[1] As a superfluous prefix, it adds visual noise, reducing immediate readability of all function declarations and subsequent usage of the variables within the function definition. Notable works or style guides [2] which do not recommend `aFoo`: [3] * Google * Linux Kernel * Bjarne Stroustrup * GCC * LLVM * Java Style (Java, non-C) * PEP 0008 (Python, non-C) * FreeBSD * Unreal Engine * Unity3D (largely C#) * Spidermonkey * Daala * RR * Rust * Folly (from Facebook) * C++ STL entrypoints * IDL for web specs on W3C and WhatWG * etc. Notable works or style guides which *do* recommend `aFoo`: * Mozilla (except for IDL, Java, and Python) * ? 3rd-party projects in our tree which do not use `aFoo`: * Cairo * Skia * ANGLE * HarfBuzz * ICU * Chromium IPC * everything under modules/ that isn't an nsFoo.c/cpp/h * etc.? 3rd-party projects in our tree which *do* recommend `aFoo`: * ? As far as I can tell, the entire industry disagrees with us (as well as a number of our own projects), which means we should have a good reason or two for making our choice. No such reason is detailed in the style guide. I propose we strike the `aFoo` recommendation from the Mozilla style guide. - [1]: Maybe it prevents accidental shadowing? No: Either this isn't allowed by spec, or at least MSVC 2013 errors when compiling this. [2]: I do not mean this as an endorsement of the listed works and guides, but rather as illustration on how unusual our choice is. [3]: I created an Etherpad into which people are welcome to gather other works, projects, or style guides that I missed: https://etherpad.mozilla.org/6FcHs9mJYQ ___ 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 07/07/2015 11:34 PM, Jeff Gilbert wrote: Outvars are good candidates for having markings in the variable name. `aFoo` for all arguments is a poor solution for this, though. On Tue, Jul 7, 2015 at 1:22 PM, smaug opet...@mozilla.com wrote: On 07/07/2015 11:18 PM, Jeff Gilbert wrote: On Tue, Jul 7, 2015 at 1:03 PM, smaug opet...@mozilla.com wrote: As someone who spends more than 50% of working time doing reviews I'm strongly against this proposal. aFoo helps with readability - reader knows immediately when the code is dealing with arguments. When and why is this useful to know? Most common case in Gecko is to know that one is assigning value to outparam. Another example where aFoo tends to be rather useful is lifetime management. If I see aFoo being used somewhere in a method after some unsafe method call (layout flush, any script callback handling, event dispatch, observer service notification etc.), I know that I need to check that the _caller_ follows COM-rules and keeps aFoo object alive during the method call. With non-aFoo variables I know the lifetime is controlled within the method. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozilla::TemporaryRef is gone; please use already_AddRefed
I brought this up on IRC, but I think this is worth taking to the list: Replacing TemporaryRef with already_AddRefed has already caused at least one leak because already_AddRefed does not call Release() on the pointer it holds if nothing takes ownership of that pointer before its destructor runs. TemporaryRef did do that, and this seems like a strictly safer approach. My question is: why doesn’t already_AddRefed call Release() in its destructor? The fact that it doesn’t seems to me to be a profoundly unintuitive footgun. I don’t think we can trust reviewers to catch this, either. The fact that Foo() is declared as: already_AddRefedBar Foo(); won’t necessarily be obvious from a call site, where the reviewer will just see: Foo(); That call will leak, and if we don’t happen to hit that code path in our tests, we may not find out about it until after shipping it. I’d prefer that already_AddRefed just call Release(), but if there are performance arguments against that, then we should be checking for this pattern with static analysis. I don’t think the situation as it stands should be allowed to remain for long. - Seth On Jun 30, 2015, at 12:02 PM, Nathan Froyd nfr...@mozilla.com wrote: Bug 1161627 has landed on inbound, which converts all uses of mozilla::TemporaryRef to already_AddRefed and removes TemporaryRef. (already_AddRefed moved to MFBT several months ago, in case you were wondering about the spreading of XPCOM concepts.) TemporaryRef was added for easier porting of code from other engines, but as it has not been used much for that purpose and it led to somewhat less efficient code in places, it was deemed a failed experiment. -Nathan ___ 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: mozilla::TemporaryRef is gone; please use already_AddRefed
On Tue, Jul 7, 2015 at 9:59 AM, Seth Fowler mfow...@mozilla.com wrote: I brought this up on IRC, but I think this is worth taking to the list: Replacing TemporaryRef with already_AddRefed has already caused at least one leak because already_AddRefed does not call Release() on the pointer it holds if nothing takes ownership of that pointer before its destructor runs. TemporaryRef did do that, and this seems like a strictly safer approach. My question is: why doesn’t already_AddRefed call Release() in its destructor? The fact that it doesn’t seems to me to be a profoundly unintuitive footgun. We have a version of already_AddRefed that automatically releases the value it holds when it's destroyed; it's called nsCOMPtr. I don’t think we can trust reviewers to catch this, either. The fact that Foo() is declared as: already_AddRefedBar Foo(); won’t necessarily be obvious from a call site, where the reviewer will just see: Foo(); Foo should be MOZ_WARN_UNUSED_RESULT (or whatever that annotation is) then, as should anything that returns an already_AddRefed. That call will leak, and if we don’t happen to hit that code path in our tests, we may not find out about it until after shipping it. Ensuring that code that is untested works is in general a hard thing to do. I'd prefer that people wrote tests. (yes, there may be edge cases in which this isn't possible) I’d prefer that already_AddRefed just call Release(), but if there are performance arguments against that, then we should be checking for this pattern with static analysis. I don’t think the situation as it stands should be allowed to remain for long. There is currently a dynamic analysis (in the form of a fatal assertion) in the already_AddRefed dtor that I added last year. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozilla::TemporaryRef is gone; please use already_AddRefed
We're already working on a static analysis in https://bugzilla.mozilla.org/show_bug.cgi?id=1180993 which will prevent code like that from passing try. Hopefully that will help with your concerns. On 2015-07-07 12:59 PM, Seth Fowler wrote: I brought this up on IRC, but I think this is worth taking to the list: Replacing TemporaryRef with already_AddRefed has already caused at least one leak because already_AddRefed does not call Release() on the pointer it holds if nothing takes ownership of that pointer before its destructor runs. TemporaryRef did do that, and this seems like a strictly safer approach. My question is: why doesn’t already_AddRefed call Release() in its destructor? The fact that it doesn’t seems to me to be a profoundly unintuitive footgun. I don’t think we can trust reviewers to catch this, either. The fact that Foo() is declared as: already_AddRefedBar Foo(); won’t necessarily be obvious from a call site, where the reviewer will just see: Foo(); That call will leak, and if we don’t happen to hit that code path in our tests, we may not find out about it until after shipping it. I’d prefer that already_AddRefed just call Release(), but if there are performance arguments against that, then we should be checking for this pattern with static analysis. I don’t think the situation as it stands should be allowed to remain for long. - Seth On Jun 30, 2015, at 12:02 PM, Nathan Froyd nfr...@mozilla.com wrote: Bug 1161627 has landed on inbound, which converts all uses of mozilla::TemporaryRef to already_AddRefed and removes TemporaryRef. (already_AddRefed moved to MFBT several months ago, in case you were wondering about the spreading of XPCOM concepts.) TemporaryRef was added for easier porting of code from other engines, but as it has not been used much for that purpose and it led to somewhat less efficient code in places, it was deemed a failed experiment. -Nathan ___ 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
Web API documentation and evangelism meeting Thursday at 8 AM PDT
The Web API documentation community meeting, with representatives from the technical evangelism and the API development teams, will take place on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your time zone). Typical meetings include news about recent API development progress and future development plans, discussions about what the priorities for documenting and promoting new Web technologies should be, and the status of ongoing work to document and evangelize these technologies. We have an agenda, as well as details on how to join, here: https://etherpad.mozilla.org/API-docs-meeting-2015-07-09. If you have topics you wish to discuss, please feel free to add them to the agenda. We look forward to seeing you there! If you have topics you wish to discuss, please feel free to add them to the agenda. Also, if you're unable to attend but have information or suggestions related to APIs on the Web, their documentation, and how we promote these APIs, please add a note or item to the agenda so we can be sure to address it, even if you're unable to attend. -- Eric Shepherd Senior Technical Writer Mozilla https://www.mozilla.org/ Blog: http://www.bitstampede.com/ Twitter: http://twitter.com/sheppy ___ 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 8, 2015 at 3:52 AM, Gabor Krizsanits gkrizsan...@mozilla.com wrote: The priority is to automatically rewrite our source with a unified style. foo - aFoo is reasonably safe, whereas aFoo-foo is not, at least with the current tools. So we either need to combine the rewrite tools with static analysis, or just go with aFoo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform +1 for consistency. Any volunteers who is willing to get rid of aFoo EVERYWHERE and someone else who is willing to review that work? If not then we should do it the other way around. At the risk of mostly repeating myself, I want to emphasize once more that: (1) We have already made the decision (in other threads) that consistency trumps everything else. (2) We will not get consistency on this issue without an automated tool. (3) We do not, at present, have an automated tool that will safely take us from aFoo - foo, but we do have the reverse. It seems like the most viable approach to leveling the playing field in (3) is to have somebody spend the time to (a) get -Wshadow working, and (b) commit to fixing all the new shadowing issues generating by an automated aFoo - foo conversions. Until we have a volunteer to do that in the near term, switching aFoo - foo basically isn't on the table. I think this issue needs to be discussed before making any more stylistic arguments in favor of abolishing aFoo. bholley ___ 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/8/2015 3:08, Gregory Szorc wrote: On Tue, Jul 7, 2015 at 5:13 PM, Jeff Gilbert jgilb...@mozilla.com wrote: On Tue, Jul 7, 2015 at 3:59 PM, Eric Rahm er...@mozilla.com wrote: I'm not a huge fan of the 'aFoo' style, but I am a huge fan of consistency. So if we want to change the style guide we should update our codebase, and I don't think we can reasonably do that automatically without introducing shadowing issues. MSVC 2013 (which I believe is our main windows compiler right now) will error during compilation if such a shadowing issue arises. Thus, if the code compiles there, `aFoo`-`foo` is safe. I would be very surprised if GCC or Clang didn't have an equivalent option. Additionally I don't spend 50% of my time reviewing, so I'd say my opinion here (meh to aFoo) is less important. It's not an undue burden for me to include an aPrefix and if we have static analysis to check for it that would make it even less of an issue. It can be a burden on the hundreds of devs who have to read and understand the code in order to write more code. With the exception of a couple people, review is not the bottleneck. The opinions of a few over-harried reviewers should not hold undue sway over the many many devs writing code. I somewhat disagree. There will always be fewer code reviewers than contributors. And, code reviewers tend to be more senior people. The time of a code reviewer thus tends to be more valuable than the time of the average code author. Coupled with the fact that code review is a barrier to landing, this translates to an incentive to make the lives and workflows of code reviewers as frictionless as possible. I feel strongly that the bandwidth limitations of code reviewers does dictate to some extent how code is written. For example, I feel that authors should spend extra effort to write detailed commit messages and split work into multiple, easier-to-review commits, as these can drastically reduce the time it takes for review. How much this reasoning extends to style and things like aFoo, I'm not sure. But if I hear a frequent code reviewer say X makes review easier, I tend to take that opinion more seriously than that of a non-reviewer. +1 Few more cents: A year ago I was not using a in my code. Then I start using it. And I got used to it! And - when used consistently - find it useful from time to time to quickly get the this is an arg variable info, both as a reviewer and a coder. So, year ago I would probably be on the get rid of it side. Now I'm definitely on the use it everywhere side. Cheers -hb- ___ 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
LGPL external library support in gecko
As of bug 1176300 landing (and hopefully sticking), we now have a place for LGPL symbols in gecko. There's a new shared library called lgpllibs (because I am horrible at naming things but it should at least be obvious what it is). Currently it holds libsoundtouch, which is LGPL with exception, but the exception is dicey so we're just dynamically linking it for sake of full compliance. It will also have symbols from libav for speedy FFTs once bug 1159469 lands. If you've had requirements for an external library with an LGPL license, we now have a place to put them. There's still some odd things that you have to do with symbol visibility to get this to work (feel free to ping me or hit #build on IRC if you have issues), and obviously licenses will still need to be vetted by gerv and added to the about:license page. This should make things easier to integrate overall though. Thanks to glandium for all the help getting this going. ___ 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 8, 2015 at 4:45 PM, Karl Tomlinson mozn...@karlt.net wrote: I think we could relax the 'a' prefix requirement to be a convention used when identifying the variable as a parameter is useful. My opinion is that this is useful for most parameters in all non-trivial functions, but others disagree. I don't think that helps. One of the primary benefits of style rules is that they eliminate (or rather, reduce) the uncertainty and churn that comes from different reviewers having different preferences. Suppose I add a new method signature in a patch. If Alice finds a-prefixing useful and Bob does not, my likelihood of receiving a review nit depends on who's reviewing it - i.e. per-reviewer style guides, which are strictly worse than per-module style guides, which are strictly worse than a single style guide. bholley ___ 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++
Bobby Holley writes: On Wed, Jul 8, 2015 at 4:45 PM, Karl Tomlinson mozn...@karlt.net wrote: I think we could relax the 'a' prefix requirement to be a convention used when identifying the variable as a parameter is useful. My opinion is that this is useful for most parameters in all non-trivial functions, but others disagree. I don't think that helps. One of the primary benefits of style rules is that they eliminate (or rather, reduce) the uncertainty and churn that comes from different reviewers having different preferences. Suppose I add a new method signature in a patch. If Alice finds a-prefixing useful and Bob does not, my likelihood of receiving a review nit depends on who's reviewing it - i.e. per-reviewer style guides, which are strictly worse than per-module style guides, which are strictly worse than a single style guide. Yes, I think you are right. That would be a likely unfortunate consequence if there is not a simple-enough set of rules to distinguish. A complicated set of rules is more trouble than it is worth to save a few letters IMO. ___ 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++
Bobby Holley writes: On Wed, Jul 8, 2015 at 3:52 AM, Gabor Krizsanits gkrizsan...@mozilla.com wrote: The priority is to automatically rewrite our source with a unified style. foo - aFoo is reasonably safe, whereas aFoo-foo is not, at least with the current tools. So we either need to combine the rewrite tools with static analysis, or just go with aFoo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform +1 for consistency. At the risk of mostly repeating myself, I want to emphasize once more that: (1) We have already made the decision (in other threads) that consistency trumps everything else. If I hear correctly, it sounds like Jeff is arguing that it is not always helpful to know that a variable is a parameter, and so it shouldn't be a requirement that parameters are always named to indicate that they are a parameter. If I were to always use firstObject for the name of the first object of immediate relevance, then this would be consistent naming. If there is only one object, then firstObject would still be a consistent name, but I wouldn't say that using the name object is inconsistent. When it is helpful to know that a variable is a parameter then consistency in the convention to identify parameters is helpful. If it is not necessary to indicate that the variable is a parameter, then it doesn't matter. If we choose the conversion to remove existing 'a' prefixes, then we would need to either automatically move to a different naming convention that clearly identifies the purposes of the variables (out params as non-const references, and maybe pointers may be specially indicated) or manually go through and work out what names to give the variables that would benefit from clear identification. The scope of the manual process of course makes this impractical. I think we could relax the 'a' prefix requirement to be a convention used when identifying the variable as a parameter is useful. My opinion is that this is useful for most parameters in all non-trivial functions, but others disagree. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
