On Wed, Oct 14, 2015 at 11:59 PM, Björn Larsson
<bjorn.x.lars...@telia.com> wrote:
> Given the reason against this RFC in the thread it would be interesting
> to know why HHVM decided to implement it?

Happy to answer, but I need to state a couple things first:
* I don't really care if this change lands.  I'd kinda like it, but
it's not solving a massive problem for me.
* There aren't any compelling reasons against this.  The only reason
given of any note that I've seen is: "There are no compelling reasons
in favor of it."  And I'll agree with that.  Like I just said, it's
not solving any major problems, and it's not going to cause any major
problems.  It's just a tiny, vanishingly insignificant piece of
syntactic sugar which disappears before we even get to the AST.

So again, could scarcely care less, so don't expect me to champion
either side, but you asked "why", so here it is: It makes code reviews
marginally less ugly.

That's it.  It's a tiny problem to solve, and likely saves less than
100ms during diff reviews, but it's a solution to a problem.

Yes, it's a problem which countless developers live with to no
significant negative consequence.  Solo developers and small shops
won't care about this since they tend to not bother with code reviews.
FB has enough engineers working on its very large codebase though,
that nobody has it all paged in, so code reviews are mandatory, and if
we can spend five minutes of effort to loosen the parser rules in
exchange for saving 1/10th of a second on every diff review that
extends/shrinks a function call/signature with no overhead, then of
course we would.  That's a fair exchange.

Apologies if you were hoping for a compelling reason.


PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to