Re: Should &&/|| really be at the end of lines?

I don't visually like ||/&& at start of line, but I can't fault the reasoning, so I'm weakly for it. I don't think it's important enough to change existing code though. On Thu, Feb 16, 2017 at 1:47 PM, wrote: > Question of the day: > When breaking overlong expressions,

Re: Intent to unship: xml:base attribute

On 2/16/17 5:52 PM, Xidorn Quan wrote: Is there any reason you think we should keep the Get/SetExplicitBaseURI API? As long as we can address its current users in some other way, no. -Boris ___ dev-platform mailing list

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 2/16/17 6:54 PM, Mats Palmgren wrote: I don't think removing -moz-appearance even has the potential of being "critical". All that happens is that you get native styling instead (at worst). There shouldn't be any loss of function. That depends. It's not hard to come up with examples where

Re: Should &&/|| really be at the end of lines?

Both are readable with judicious indentation on wrapping. If you must recompose the entire expression in your mind, the code is too terse, and we should consider cleaning it up and making it more readable. &&/|| position will not make or break this. On Thu, Feb 16, 2017 at 3:10 PM, Jean-Yves

Re: Should &&/|| really be at the end of lines?

Jeff, I see you're opinionated against consistency. :-) Or you think there are other more important things? Anyway, I'm not exactly sure what you're advocating. Could you please elaborate? On Friday, February 17, 2017 at 10:11:25 AM UTC+11, Jeff Gilbert wrote: > I would not assume that's

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 02/16/2017 07:20 PM, Benjamin Smedberg wrote: It has happened repeatedly over the past two years that we discovered critical issues that affect websites only after we ship to release. I don't think removing -moz-appearance even has the potential of being "critical". All that happens is

Re: Should &&/|| really be at the end of lines?

Thank you David. Your opinion about any *future* change to &&/|| style would be appreciated. ;-) About "increased disruption to blame that makes understanding the history of our code harder": I think some tools like http://searchfox.org/ have considerably lessened the impact to blame, because

Re: Should &&/|| really be at the end of lines?

If there are so many parens that we require an editor to disambiguate them, it's too dense. Add whitespace or decompose the expression until readable. On Thu, Feb 16, 2017 at 3:15 PM, Mike Hommey wrote: > On Fri, Feb 17, 2017 at 12:10:32AM +0100, Jean-Yves Avenard wrote: >>

Re: Should &&/|| really be at the end of lines?

On Thursday 2017-02-16 15:11 -0800, Jeff Gilbert wrote: > I would not assume that's necessarily going to happen without > contention. Consistency is not a goal in and of itself. Using clang-format on the entire tree has the massive value of: * reviewers not needing to point out whitespace and

Re: Intent to unship: xml:base attribute

On Fri, Feb 17, 2017, at 01:38 AM, Ehsan Akhgari wrote: > On 2017-02-16 1:51 AM, Xidorn Quan wrote: > > Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=903372 > > > > Summary: > > * It has been removed from the spec years ago. > > * No other browser supports it. > > * We pay

Re: Should &&/|| really be at the end of lines?

On Fri, Feb 17, 2017 at 12:10:32AM +0100, Jean-Yves Avenard wrote: > reading this: (turn on courier) > > return ((aCodecMask & VPXDecoder::VP8) > && aMimeType.EqualsLiteral("video/webm; codecs=vp8")) > || ((aCodecMask & VPXDecoder::VP9) > &&

Re: Should &&/|| really be at the end of lines?

I'll not get into why I disagree with your points about format-the-world here. Let's leave that for elsewhere. Here's my take on the example at hand: https://pastebin.mozilla.org/8979527 In this case, I do like the latter two best. (Old-style and simplification) On Thu, Feb 16, 2017 at 3:25 PM,

Re: Intent to unship: xml:base attribute

On Fri, Feb 17, 2017, at 01:36 AM, Boris Zbarsky wrote: > On 2/16/17 7:12 AM, Xidorn Quan wrote: > > The perf penalty of xml:base is basically that we have to dynamically > > construct a URL from bottom to top along the tree whenever we need a > > base URL of an element. And since this URL may be

Re: Should &&/|| really be at the end of lines?

Hi On 16/02/17 23:56, Jeff Gilbert wrote: I don't visually like ||/&& at start of line, but I can't fault the reasoning, so I'm weakly for it. I don't think it's important enough to change existing code though. Disclaimer: I'm now biased about this. I've been writing C and C++ code for now

Re: Should &&/|| really be at the end of lines?

I would not assume that's necessarily going to happen without contention. Consistency is not a goal in and of itself. On Thu, Feb 16, 2017 at 3:04 PM, wrote: > There's an ongoing effort to use clang-format to automatically format All The > Codes [1], so I think we should

Re: Should &&/|| really be at the end of lines?

On Fri, Feb 17, 2017 at 12:25 PM, L. David Baron wrote: > Using clang-format on the entire tree has the massive value of: > > * reviewers not needing to point out whitespace and indentation issues > > * reduced friction for new contributors (being able to use a tool >

Re: Should &&/|| really be at the end of lines?

On Fri, Feb 17, 2017 at 10:39 AM, Robert O'Callahan wrote: >> Using clang-format on the entire tree has the massive value of: > > Also, it's very liberating not having to think about formatting while > writing code, knowing it will be automatically fixed up later. This is >

Should &&/|| really be at the end of lines?

Question of the day: When breaking overlong expressions, should &&/|| go at the end or the beginning of the line? TL;DR: Coding style says 'end', I think we should change it to 'beginning' for better clarity, and consistency with other operators. Our coding style reads: "Break long conditions

Re: Mozilla naming style vs. C++ standard library containers

On Feb 16, 2017 9:09 PM, "Botond Ballo" wrote: On Thu, Feb 16, 2017 at 1:05 PM, smaug wrote: > AFAIK, uncapitalized method names in MFBT are the old style, and new code > should just > use Mozilla coding style. > This was discussed in some other thread in

Re: Should &&/|| really be at the end of lines?

There's an ongoing effort to use clang-format to automatically format All The Codes [1], so I think we should try and make sure we agree (or at least settle*) on a coding style when it's going to be enforced everywhere. ;-) * I'm presenting my own preferences here, but in the end I'm fine with

Re: Should &&/|| really be at the end of lines?

Of course grepping agrees with you, since it's been the coding style so far! ;-) I was hoping to change that, if most people agreed. While it's good to know how many people are for or against it, so that we get a sense of where the majority swings, I'd really like to know *why* people have

Re: Tool for converting C++ standard library naming style to Gecko naming style?

On 2017-02-16 7:41 AM, Henri Sivonen wrote: > Is there some kind of tool, similar to ./mach clang-format for > whitespace, that changes identifies from C++ standard library style to > Gecko style? > > I.e. foo becomes Foo, foo_bar becomes FooBar and arguments and members > get prefixed with a and

Re: Intent to unship: xml:base attribute

On 2/16/17 7:12 AM, Xidorn Quan wrote: The perf penalty of xml:base is basically that we have to dynamically construct a URL from bottom to top along the tree whenever we need a base URL of an element. And since this URL may be constructed dynamically, the caller would have to hold a strong

Tool for converting C++ standard library naming style to Gecko naming style?

Is there some kind of tool, similar to ./mach clang-format for whitespace, that changes identifies from C++ standard library style to Gecko style? I.e. foo becomes Foo, foo_bar becomes FooBar and arguments and members get prefixed with a and m respectively? -- Henri Sivonen hsivo...@hsivonen.fi

Re: Intent to unship: xml:base attribute

On 2017-02-16 1:51 AM, Xidorn Quan wrote: > Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=903372 > > Summary: > * It has been removed from the spec years ago. > * No other browser supports it. > * We pay performance penalty for it. > * It makes things trickier for stylo to handle URL

Re: Intent to unship: xml:base attribute

On Thu, Feb 16, 2017, at 10:25 PM, Gijs Kruitbosch wrote: > On 16/02/2017 06:51, Xidorn Quan wrote: > > Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=903372 > > > > Summary: > > * It has been removed from the spec years ago. > > * No other browser supports it. > > * We pay performance

Re: Intent to unship: xml:base attribute

On 16/02/2017 06:51, Xidorn Quan wrote: Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=903372 Summary: * It has been removed from the spec years ago. * No other browser supports it. * We pay performance penalty for it. * It makes things trickier for stylo to handle URL values. The

Re: We should drop MathML

Yeah, somebody shared the link with me and I didn't notice the date. My bad. That said, I'm glad to hear that Firefox isn't seriously considering dropping MathML! Phil This message optimized for indexing by NSA PRISM On Wed, Feb 15, 2017 at 2:00 PM, Jonathan Kingston

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 02/11/2017 04:59 AM, Boris Zbarsky wrote: The biggest worry for me is that inline style is never a "chrome sheet" in this sense. That's a valid concern, but I think ignoring -moz-appearance has fairly benign effects in most cases. And as Jet pointed out to me, just landing it and see what

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 2/16/17 10:23 AM, Mats Palmgren wrote: That's a valid concern, but I think ignoring -moz-appearance has fairly benign effects in most cases. Well, as in things just look wrong, is all, right? And as Jet pointed out to me, just landing it and see what breaks is standard procedure for

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 02/16/2017 04:27 PM, Boris Zbarsky wrote: On 2/16/17 10:23 AM, Mats Palmgren wrote: That's a valid concern, but I think ignoring -moz-appearance has fairly benign effects in most cases. Well, as in things just look wrong, is all, right? Right. But as I said, at least in some cases it

Mozilla naming style vs. C++ standard library containers

It seems that we already have MFBT code that has lower case methods begin/end/cbegin/cend, etc., for compatibility with C++ standard library iteration: https://dxr.mozilla.org/mozilla-central/source/mfbt/ReverseIterator.h#136 I guess these methods shouldn't be capitalized, then. It seems that

Re: Mozilla naming style vs. C++ standard library containers

On 02/16/2017 07:24 PM, Henri Sivonen wrote: It seems that we already have MFBT code that has lower case methods begin/end/cbegin/cend, etc., for compatibility with C++ standard library iteration: https://dxr.mozilla.org/mozilla-central/source/mfbt/ReverseIterator.h#136 I guess these methods

Re: Mozilla naming style vs. C++ standard library containers

On 02/16/2017 08:05 PM, smaug wrote: On 02/16/2017 07:24 PM, Henri Sivonen wrote: It seems that we already have MFBT code that has lower case methods begin/end/cbegin/cend, etc., for compatibility with C++ standard library iteration:

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

I'm surprised and disheartened that "land it and see what breaks" is considered an acceptable strategy for pretty much any commit, but especially for web compat. We *don't* see what breaks fast enough or before things hit the release population. We cannot currently rely on our prerelease

Re: Mozilla naming style vs. C++ standard library containers

On Thu, Feb 16, 2017 at 1:05 PM, smaug wrote: > AFAIK, uncapitalized method names in MFBT are the old style, and new code > should just > use Mozilla coding style. > This was discussed in some other thread in dev.platform, but I can't find it > right now. In the case of begin()

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On Thu, Feb 16, 2017 at 7:23 AM, Mats Palmgren wrote: > On 02/11/2017 04:59 AM, Boris Zbarsky wrote: > >> The biggest worry for me is that inline style is never a "chrome sheet" >> in this sense. >> > > That's a valid concern, but I think ignoring -moz-appearance has fairly >

Re: Should &&/|| really be at the end of lines?

I personally have a strong preference for operators at the end of lines. The codebase seems to agree with me, judging by some rough grepping ('fff' is an alias I have that's roughly equivalent to rgrep): $ fff "&&$" | wc -l 28907 $ fff "^ *&&" | wc -l 3751 $ fff "||$" | wc -l 26429 $ fff

Re: Should &&/|| really be at the end of lines?

One thing I like about trailing operators is that they tend to match what you'd find in bullet-point prose. Here's a made-up example: You can apply for a refund of your travel insurance policy if: * You cancel within 7 days of purchase, and * You have not yet begun your journey, and * You have