On Mon, Dec 15, 2014 at 8:56 AM, Derick Rethans der...@php.net wrote:
On Sun, 14 Dec 2014, George Bond wrote:
If you wanted an upgrade path that was not Evil (in the sense of not
introducing subtle and hard-to-diagnose bugs), could you not change
the operator to be *un*associative in PHP7?
Hi!
Precisely why I suggested we do a poll and find out. Polling is a valid
means of getting a reasonable accounting of a particular metric.
If you do it in a professional way, with properly randomized samples,
controlled statistics, etc. Putting a form on the internet and counting
people
Hi all,
On Tue, Dec 16, 2014 at 6:17 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
Precisely why I suggested we do a poll and find out. Polling is a valid
means of getting a reasonable accounting of a particular metric.
If you do it in a professional way, with properly randomized
On Tue, Dec 16, 2014 at 06:48:14PM +0900, Yasuo Ohgaki wrote:
Instead of polling people, how about provide a compatibility check script?
This would be easy with tokenizer, I suppose.
+1
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
On Sun, 14 Dec 2014, George Bond wrote:
If you wanted an upgrade path that was not Evil (in the sense of not
introducing subtle and hard-to-diagnose bugs), could you not change
the operator to be *un*associative in PHP7? That would effectively
just make concrete the
On Dec 14, 2014, at 23:50, Leon Sorokin leeon...@gmail.com wrote:
On 12/14/2014 10:45 PM, Robert Williams wrote:
I strongly suspect far more code would be *fixed* if the ternary operator
were changed to match what other languages do.
If you have 'incorrectly' functioning code today that
Leon Sorokin wrote on 13/12/2014 22:45:
Hi guys,
I was wondering if 7.0 could be the version to fix the long-standing
incorrect ternary associativity bug in PHP [1]. This seems especially
worthy of reconsideration since the Null Coalesce RFC has been
accepted and merged [2] with the correct
Hi!
The fact that it *may* break *some* code that is used somewhere despite
documentation recommending against it (pretty much deprecating it
already for years) is a terrible reason not to re-evaluate the situation
given the huge opportunity to correct this.
It *will* break some code.
On Mon, Dec 15, 2014 at 12:11 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
The fact that it *may* break *some* code that is used somewhere despite
documentation recommending against it (pretty much deprecating it
already for years) is a terrible reason not to re-evaluate the
On 12/15/2014 2:11 PM, Stanislav Malyshev wrote:
There's not that many breaking changes accepted, and each of them had to
be substantiated. We had other breaking changes is not a
substantiation. For example, most uses of associativity are wrong ones
- is, but that makes the idea of
On 12/15/2014 11:59 AM, Robert Williams wrote:
What world is this that you live in where every line of code that’s written is
fully unit-tested
You took my example too literally; forget the unit tests. Imagine the
situation differently:
1. Someone wrote this function:
function
On Mon, Dec 15, 2014 at 8:19 PM, Leon Sorokin leeon...@gmail.com wrote:
On 12/15/2014 11:59 AM, Robert Williams wrote:
What world is this that you live in where every line of code that’s
written is fully unit-tested
You took my example too literally; forget the unit tests. Imagine the
On 12/14/2014 12:51 AM, Levi Morrison wrote:
While I think long-term this would be a beneficial change I think in
the short term it's quite a hurdle.
This discussion will be identical whether we wait till PHP7 or PHP9 in a
decade. The longer this change takes to make, the more code that will
On 14 December 2014 at 08:24, Leon Sorokin leeon...@gmail.com wrote:
On 12/14/2014 12:51 AM, Levi Morrison wrote:
While I think long-term this would be a beneficial change I think in
the short term it's quite a hurdle.
This discussion will be identical whether we wait till PHP7 or PHP9 in
On 14 Dec 2014, at 12:01, George Bond happy.melon.wiki...@gmail.com wrote:
If you wanted an upgrade path that was not Evil (in the sense of not
introducing subtle and hard-to-diagnose bugs), could you not change the
operator to be *un*associative in PHP7? That would effectively just make
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Sunday, December 14, 2014 2:26 PM
To: George Bond
Cc: PHP internals
Subject: Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
On 14 Dec 2014, at 12:01, George Bond
happy.melon.wiki...@gmail.com wrote
This sounds like a reasonable compromise to me and infinitely better
than doing nothing. However, if 7.0 complains loudly enough about this
already quasi-deprecated pattern, then the incubation period for an
eventual fix need not be that of a decade-out major version, but of a
7.x point
On 14 December 2014 17:31:52 GMT, Leon Sorokin leeon...@gmail.com wrote:
This sounds like a reasonable compromise to me and infinitely better
than doing nothing. However, if 7.0 complains loudly enough about this
already quasi-deprecated pattern, then the incubation period for an
eventual fix
On 14/12/14 19:48, Rowan Collins wrote:
5.4 is a good example of what we *don't* want to do with minor versions. It
consisted of a messy list of those bits of the abandoned 6 which didn't
quite make it into 5.3.
5.4 should have been '6' with a 5.4 that provided the very same buffer
that 5.7
Some thoughts from user land…
On the concern of breaking code out there that relies on the current behavior,
I strongly suspect far more code would be *fixed* if the ternary operator were
changed to match what other languages do. I hate to admit it, but my own shop
is a good example. We have a
On 12/14/2014 10:45 PM, Robert Williams wrote:
I strongly suspect far more code would be *fixed* if the ternary operator were
changed to match what other languages do.
I appreciate your support, but either I am not understanding you, or
your reasoning is unsound.
If you have 'incorrectly'
Hi guys,
I was wondering if 7.0 could be the version to fix the long-standing
incorrect ternary associativity bug in PHP [1]. This seems especially
worthy of reconsideration since the Null Coalesce RFC has been accepted
and merged [2] with the correct associativity [3].
The major version
Hey Leon,
On 13 Dec 2014, at 22:45, Leon Sorokin leeon...@gmail.com wrote:
I was wondering if 7.0 could be the version to fix the long-standing
incorrect ternary associativity bug in PHP [1]. This seems especially worthy
of reconsideration since the Null Coalesce RFC has been accepted and
On Sat, 13 Dec 2014, Leon Sorokin wrote:
I was wondering if 7.0 could be the version to fix the long-standing
incorrect ternary associativity bug in PHP [1].
It is not a bug, as the issue's status says: Not a bug.
This seems especially worthy of reconsideration since the Null
Coalesce RFC
I wonder how many people use ternary operators in an associative context.
My suspicion is that little of those that do really intend PHP
associativity.
But it'd need quite a parser to detect the affected usage.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Respectfully,
PHP's 'Unexpected behavior is not a bug' stance is pretty infuriating;
the utterly ridiculous T_PAAMAYIM_NEKUDOTAYIM argument comes to mind.
It is not a bug, as the issue's status says: Not a bug.
I can understand why this would have been a 'wontfix' for versions
pre-7.0.
On Sat, Dec 13, 2014 at 4:53 PM, Leon Sorokin leeon...@gmail.com wrote:
Respectfully,
PHP's 'Unexpected behavior is not a bug' stance is pretty infuriating; the
utterly ridiculous T_PAAMAYIM_NEKUDOTAYIM argument comes to mind.
It is not a bug, as the issue's status says: Not a bug.
I can
On 14/12/2014 00:53, Leon Sorokin wrote:
Respectfully,
PHP's 'Unexpected behavior is not a bug' stance is pretty infuriating
[...]
Documentation of unexpected behavior does not make something 'not a bug'.
Whether or not this particular bug is fixable, I do agree with this:
we're not going
While I think long-term this would be a beneficial change I think in
the short term it's quite a hurdle. There is definitely code out there
relying on this behavior and changing it will result in the worst BC
case: it will not fail in any way but will instead act differently.
I definitely want to
29 matches
Mail list logo
