rfc:array-to-string

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:array-to-string [2015/01/11 13:25] – francoisrfc:array-to-string [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 1: Line 1:
 ====== Improve array to string conversion ====== ====== Improve array to string conversion ======
-  * Version: 1.0+  * Version: 2.1
   * 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, <francois@tekwire.net> 
-  * Status: Under discussion+  * Status: Withdrawn
   * First Published at: http://wiki.php.net/rfc/array-to-string   * First Published at: http://wiki.php.net/rfc/array-to-string
 +
 +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 =====
Line 19: Line 23:
 E_NOTICE and 'Array'. E_NOTICE and 'Array'.
  
-I consider this as +We consider this as no more than a temporary half-backed solution : we raise a low-level error 
-a half-backed solution : we raise an error, which is not a 'real' +and we return a useless string.
-error (an E_WARNING would be) and we return a useless string (anybody relying on the 'Array' value, please call me :). +
-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 is to have +Now, the release of a new major version is the occasion to make a definitve decision.
-stopped a flame war or for (wrong) BC reasons.+
  
-Now, the future release of a new major version may be the occasion +  Note: the RFC originally proposed, either to fully support the feature, or to deprecate it. 
-to get rid of this. I know this is it a hot subject but I hope we can all +  Following discussion, it was decided to only propose the option of deprecating it. 
-give our opinion without starting another war. +  So the other option was removed, and can be consulted via older versions of the RFC.
- +
-I imagine two possible alternative and opposite behaviors :+
  
 ==== 1st alternative: deprecate ==== ==== 1st alternative: deprecate ====
  
 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 and that we have been pulling this problematic behavior behind us for years. +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' method: +Another argument is that there never was an agreement on the 'standard' way 
-conversion attempt generates a 'fatal catchable error'. Then, +to convert an array to a string.
-if the program was still alive, the conversion would return 'Array' as before.+
  
-It is a radical message to the developers that we don't support this feature anymore, +So, we propose that Array-to-string conversions are considered exactly the same 
-and that fixing code is a pre-requisite to a PHP7 switch.+as object-to-string with no '__toString' method: 
 +any conversion attempt generates an E_RECOVERABLE_ERROR. Then, 
 +if the program is still alive, the conversion returns 'Array' as before. The E_NOTICE 
 +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 be skipped.+that, since an E_NOTICE is currently generated, it may be considered as a 
 +deprecation notice, and we can directly switch to E_RECOVERABLE_ERROR.
  
-I am not favorable to this alternative as, although it is more clear than the current +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 choice.+always better to introduce a BC break in a major version. 
 + 
 +If 5.7 is revived, it will contain an interim version, with E_NOTICE replaced by E_DEPRECATED.
  
 ==== 2nd alternative: full support ==== ==== 2nd alternative: full support ====
  
-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 'glue'). +
-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 'toString' method, and would raise a fatal catchable method otherwise. +
- +
-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't +
-paint the bike shed again, but the most important is to define +
-a //standard// conversion mechanism and ensure it never changes.+
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
  
-If we deprecate array-to-string, the potential BC break is huge as a lot of existing +The potential BC breaks 
-PHP code requires turning off E_NOTICE, and the 'Array' value, while useless, +are important because a lot of PHP code runs in E_NOTICE-disabled environments and 
-can go unnoticed for a lot of reasons.+the 'Array' return value, while probably invalid, may easily go unnoticed.
  
-If we add full support, the removal of E_NOTICE has a negligible impact. And, as all of us +In balance of this, we can consider that raising the error level in environments 
-probably agree that anybody relying on the 'Array' string should choose another profession, +where E_NOTICE messages are disabled, will generally help discovering bugs that had 
-the overall BC break remains minimal.+remained unnoticed because the error level was hidden. 
 + 
 +Actually, during the discussion, the opinions seemed to converge towards 
 +the position that discovering undetected bugs is probably more important than 
 +potential BC breaks.
  
 ===== 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 conversions, in C or PHP code.+Touches every explicit or implicit array-to-string conversion, whether called 
 +from extensions or in PHP code.
  
 ===== Open Issues ===== ===== Open Issues =====
  
-None (yet)+None
  
 ===== Unaffected PHP Functionality ===== ===== Unaffected PHP Functionality =====
  
-No other zval type conversion should be impacted.+No other type conversion is impacted.
  
 ===== Future Scope ===== ===== Future Scope =====
Line 109: Line 98:
 ===== Proposed Voting Choices ===== ===== Proposed Voting Choices =====
  
-Required majority : 2/3, and even probably more :)+Basic Yes/No : Yes to replace E_NOTICE with E_RECOVERABLE_ERROR, No for no change.
  
-===== Patches and Tests =====+<doodle title="array-to-string" auth="francois" voteType="single" closed="false"> 
 +   * Yes 
 +   * No 
 +</doodle>
  
-Implementation is easy.+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 tests is under way.
  
 ===== Implementation ===== ===== Implementation =====
Line 125: Line 121:
  
 ===== References ===== ===== References =====
 +
 +PR : https://github.com/php/php-src/pull/991
 +
 +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.1420982739.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools