rfc:array-to-string
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
rfc:array-to-string [2015/01/11 01:06] – francois | rfc:array-to-string [2017/09/22 13:28] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== | + | ====== |
- | * Version: | + | * Version: |
* Creation date: 2015-01-10 | * Creation date: 2015-01-10 | ||
- | * Last modification date : 2015-01-11 | + | * Last modification date : 2016-02-02 |
- | * Author: François Laupretre, francois@tekwire.net | + | * Author: François Laupretre, |
- | * Status: | + | * Status: |
* First Published at: http:// | * First Published at: http:// | ||
+ | |||
+ | This RFC is withdrawn because discussion shows that the subject is far from mature | ||
+ | and potential side effects require more discussions. It will probably be revived | ||
+ | in the future but potential BC breaks reserve such changes for a major release. | ||
===== Introduction ===== | ===== Introduction ===== | ||
- | Currently, array to string conversion raises an E_NOTICE and returns a string | + | Currently, array to string |
containing ' | containing ' | ||
- | This RFC considers this behavior as non-optimal and proposes | + | This RFC considers this behavior as non-optimal and proposes |
===== Proposal ===== | ===== Proposal ===== | ||
Line 19: | Line 23: | ||
E_NOTICE and ' | E_NOTICE and ' | ||
- | I consider this as | + | We consider this as no more than a temporary |
- | a half-backed solution : we raise an error, which is not a ' | + | and we return a useless string. |
- | error (an E_WARNING would be) and we return a useless string | + | |
- | Off topic: I am personally against the existence of E_NOTICE and E_STRICT, which | + | |
- | are, IMO, half-backed solutions too. | + | |
- | The only possible justification I imagine for the current behavior | + | Now, the release of a new major version |
- | stopped | + | |
- | Now, the future release of a new major version may be the occasion | + | Note: the RFC originally proposed, either to fully support |
- | to get rid of this. I know this is it a hot subject but I hope we can all | + | |
- | give our opinion without starting another war. | + | So the other option was removed, |
- | + | ||
- | I imagine two possible alternative | + | |
==== 1st alternative: | ==== 1st alternative: | ||
Here, we consider that array-to-string conversion was never actively supported nor | Here, we consider that array-to-string conversion was never actively supported nor | ||
- | encouraged | + | encouraged, that, it most cases, its only effect is hiding bugs, and that it is time to disable it definitely. |
- | So, it may be time to disable it definitely. | + | |
- | So, array-to-string conversion would be considered like object-to-string with no 'toString' | + | Another argument is that there never was an agreement on the 'standard' |
- | conversion attempt generates | + | to convert an array to a string. |
- | if the program was still alive, the conversion would return ' | + | |
- | It is a radical message | + | So, we propose that Array-to-string conversions are considered exactly |
- | and that fixing code is a pre-requisite to a PHP7 switch. | + | as object-to-string with no '__toString' |
+ | any conversion attempt generates an E_RECOVERABLE_ERROR. Then, | ||
+ | if the program is still alive, the conversion returns ' | ||
+ | message is suppressed. | ||
+ | No more worries about hiding bugs with this logic, as masking such an error level is a strong | ||
+ | user decision, definitely not the same as disabling E_NOTICE. | ||
- | We could go through a migration phase with an E_DEPRECATED but the 5.7 was rejected | + | We could go through a migration phase using E_DEPRECATED, but we consider |
- | and we already raise an E_NOTICE. So, this phase may probably | + | that, since an E_NOTICE |
+ | deprecation notice, and we can directly switch to E_RECOVERABLE_ERROR. | ||
- | I am not favorable to this alternative as, although | + | Another argument is that, while this one should not be very problematic, it is |
- | behavior, I think that the second one below is a better | + | always |
+ | |||
+ | If 5.7 is revived, it will contain an interim version, with E_NOTICE replaced by E_DEPRECATED. | ||
==== 2nd alternative: | ==== 2nd alternative: | ||
- | Here, we decide that array-to-string conversion is a valid concept. We define a | + | Removed |
- | standard algorithm to perform the conversion, fix it in stone and | + | |
- | encourage C and PHP code to use it with no restriction. | + | |
- | + | ||
- | Of course, the first step is to remove the E_NOTICE. | + | |
- | + | ||
- | The 2nd step is the choice of the conversion algorithm. What I suggest is the | + | |
- | most intuitive choice I would expect in this case : a | + | |
- | recursive concatenation of every non-array elements of the | + | |
- | array tree, each of them converted to a string (a recursive implode() with no ' | + | |
- | Array elements would be taken in array order, keys would be ignored. | + | |
- | + | ||
- | Existing rules for non-array types to string conversions would be applied to all | + | |
- | non-array members of the input array. For instance, if the array | + | |
- | contains an object, it would be silently converted to string if the class defines | + | |
- | a ' | + | |
- | + | ||
- | I prefer this alternative as it adds a standard, meaningful way to convert an array to | + | |
- | a string. There will be discussions on the algorithm to choose and I hope we won' | + | |
- | paint the bike shed again, but the most important is to define | + | |
- | a // | + | |
===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== | ||
- | If we deprecate array-to-string, | + | The potential BC breaks |
- | PHP code requires turning off E_NOTICE, and the ' | + | are important because |
- | can go unnoticed | + | the ' |
- | If we add full support, the removal of E_NOTICE | + | In balance of this, we can consider that raising |
- | probably agree that anybody relying on the ' | + | where E_NOTICE |
- | the overall | + | remained unnoticed because |
+ | |||
+ | Actually, during the discussion, the opinions seemed to converge towards | ||
+ | the position that discovering undetected bugs is probably more important than | ||
+ | potential | ||
===== Proposed PHP Version(s) ===== | ===== Proposed PHP Version(s) ===== | ||
- | PHP 7 | + | 7.0 |
===== RFC Impact ===== | ===== RFC Impact ===== | ||
- | Trivial. | + | Touches every explicit or implicit array-to-string |
+ | from extensions or in PHP code. | ||
===== Open Issues ===== | ===== Open Issues ===== | ||
- | None (yet) | + | None |
===== Unaffected PHP Functionality ===== | ===== Unaffected PHP Functionality ===== | ||
- | No other zval type conversion | + | No other type conversion |
===== Future Scope ===== | ===== Future Scope ===== | ||
Line 109: | Line 98: | ||
===== Proposed Voting Choices ===== | ===== Proposed Voting Choices ===== | ||
- | Required majority | + | Basic Yes/ |
- | ===== Patches and Tests ===== | + | <doodle title=" |
+ | * Yes | ||
+ | * No | ||
+ | </ | ||
- | Very easy to implement. | + | Voting will close March 6th, 00:00 (UTC). |
- | Patches and tests will be written as soon as we seem to agree on something. | + | Required majority : 2/3 of voters. |
+ | |||
+ | ===== Patches and Tests ===== | ||
+ | |||
+ | Patch provided, fixing existing | ||
===== Implementation ===== | ===== Implementation ===== | ||
Line 125: | Line 121: | ||
===== References ===== | ===== References ===== | ||
+ | |||
+ | PR : https:// | ||
+ | |||
+ | 32 tests are broken by this change. The coresponding fixes are under way and not | ||
+ | included in the PR. | ||
===== Rejected Features ===== | ===== Rejected Features ===== |
rfc/array-to-string.1420938376.txt.gz · Last modified: 2017/09/22 13:28 (external edit)