On Fri, Feb 17, 2017 at 1:28 AM, wrote:
> 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 their position. (I could learn something!)
I prefer having the operator at the beginning o
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 not
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
their
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 "
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
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
dev-platform@lists.mozilla.o
Let's drop this side-topic from this thread.
On Thu, Feb 16, 2017 at 4:40 PM, Martin Thomson wrote:
> 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 format
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
> especially helpful for
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 th
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 that
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
>instead of repeatedly it
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, L
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 in
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 necessari
On 17/02/17 00:17, Jeff Gilbert wrote:
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.
I'd love to know how adding any whitespaces could make any logical
expressions clearer that what I post
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:
>> reading this: (turn on
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)
> && aMimeType.EqualsLitera
Forgot the link:
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1188202
On Friday, February 17, 2017 at 10:04:49 AM UTC+11, gsqu...@mozilla.com wrote:
> 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
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 Avena
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 try and make sure we ag
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 m
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 performance
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
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, should &&/|| go at the end
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 c
On Thu, Feb 16, 2017 at 02:41:11PM +0200, 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 p
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 dev.platform, but I can't find
it
> righ
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&others think we should change it to
'beginning' for better clarity, and consistency with other operators.
Our coding style reads:
"Break long cond
On Thursday 2017-02-16 13:20 -0500, Benjamin Smedberg wrote:
> 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.
I don't think this is a realistic argument. Basically any change we
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
> benign effects in mo
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() and end(), it's no
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 population
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 sho
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:
https://dxr.mozilla.org/mozilla-central/source/mfbt/ReverseIte
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 eve
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 act
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 unpref
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 b
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
wrote:
> Hi Phil,
>
> I
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 refer
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
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
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
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
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 t
45 matches
Mail list logo
