rfc:var-export-array-syntax

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:var-export-array-syntax [2020/03/30 16:02] googleguyrfc:var-export-array-syntax [2020/04/10 09:24] (current) – typos, examples guilliamxavier
Line 12: Line 12:
  
 ===== Proposal ===== ===== Proposal =====
-Instead of+This change proposes adding a third optional argument for ''var_export()'' and 3 new bit-wise flags as follows:
  
-<code php>array(1, 2, 3)</code>+  - VAR_EXPORT_SHORT_ARRAY 
 +  - VAR_EXPORT_NO_INDEX 
 +  - VAR_EXPORT_COMPACT
  
-''var_export()'' would produce+''VAR_EXPORT_SHORT_ARRAY'' triggers the short-hand syntax for arrays which affects all 3 cases (arrays, stdClass objects, other classes objects). ''VAR_EXPORT_NO_INDEX'' will discard sequential numbered indexes starting from 0, which is currently the default behavior to include them. ''VAR_EXPORT_COMPACT'' will compact the output to one line rather than adding the additional new line characters at each stage.
  
-<code php>[12, 3]</code>+Each option can be used aloneand can also be combined with other(s).
  
-This will effect things like ''stdClass'' and ''set_state'' as well since they are cast to objects from array literals and they use the long-form array syntax above. 
  
-So the following changes are also in effect:+For example, <php>var_export([1, 2, 3]);</php> produces 
 + 
 +<code php> 
 +array ( 
 +  0 => 1, 
 +  1 => 2, 
 +  2 => 3, 
 +
 +</code> 
 + 
 +and the new <php>var_export([1, 2, 3], false, VAR_EXPORT_SHORT_ARRAY);</php> would produce 
 + 
 +<code php> 
 +
 +  0 => 1, 
 +  1 => 2, 
 +  2 => 3, 
 +
 +</code> 
 + 
 +This would affect ''stdClass'' and other classes objects as well since they are exported using array literals (for ''(object)'' casting or ''%%__set_state()%%'' call) and they use the long-form array syntax above. 
 + 
 +So the following changes would also be in effect:
  
 <code php> <code php>
Line 30: Line 53:
  
 var_export($obj); var_export($obj);
- 
 /* /*
-Gives us: 
 (object) array( (object) array(
    'foo' => 'bar',    'foo' => 'bar',
    'baz' => 'quix',    'baz' => 'quix',
 ) )
 +*/
  
-With the new change it would be +var_export($obj, false, VAR_EXPORT_SHORT_ARRAY); 
 +/*
 (object) [ (object) [
    'foo' => 'bar',    'foo' => 'bar',
Line 47: Line 69:
 </code> </code>
  
-The same happens for classes:+Same for other classes:
  
 <code php> <code php>
Line 55: Line 77:
  
 var_export(new Foo); var_export(new Foo);
- 
 /* /*
-Gives us: 
 Foo::__set_state(array( Foo::__set_state(array(
    'bar' => 'baz',    'bar' => 'baz',
 )) ))
 +*/
  
-With the changes it would be:+var_export(new Foo, false, VAR_EXPORT_SHORT_ARRAY); 
 +/*
 Foo::__set_state([ Foo::__set_state([
    'bar' => 'baz',    'bar' => 'baz',
Line 69: Line 91:
 </code> </code>
  
-===== Backward Incompatible Changes ===== +Using the other bitwise flags you could also do things like...
-There shouldn't be any backwards incompatible changes as ''var_export()'' will continue to produce valid PHP code such that ''var_export()'' to PHP and PHP back to ''var_export()'' will continue to work as expectedThe syntax changes are all forwards compatible as of PHP 5.4 so we shouldn't see any issues here.+
  
-However, there are some tests that test the output of ''var_export''though I view this as a broken test more than I do a BC change. I liken this to a test which uses the value of a constant like ''E_ALL'' rather than just using the constant itself in testing that the constant works. Why not just test that ''var_export'' gives you back an array rather than test its output? It's all valid PHP code that we care about not the output itself. The output valuelike the constant valueis subject to change. That's why we use it in the first place. To prevent change from effecting the test (constant).+<code php> 
 +var_export([123]false, VAR_EXPORT_NO_INDEX); 
 +/* 
 +array ( 
 +  1, 
 +  2, 
 +  3, 
 +) 
 +*/
  
-I hope that's clear.+var_export([1, 2, 3], false, VAR_EXPORT_COMPACT); 
 +/* 
 +array (0 => 1, 1 => 2, 2 => 3) 
 +*/ 
 +</code>
  
-In the event that this RFC is voted through I willhowever, be updating these tests.+and combine them... 
 + 
 +<code php> 
 +var_export([123], false, VAR_EXPORT_SHORT_ARRAY | VAR_EXPORT_NO_INDEX); 
 +/* 
 +
 +  1, 
 +  2, 
 +  3, 
 +
 +*/ 
 + 
 +var_export([1, 2, 3], false, VAR_EXPORT_SHORT_ARRAY | VAR_EXPORT_COMPACT); 
 +/* 
 +[0 => 1, 1 => 2, 2 => 3] 
 +*/ 
 + 
 +var_export([1, 2, 3], false, VAR_EXPORT_NO_INDEX | VAR_EXPORT_COMPACT); 
 +/* 
 +array (1, 2, 3) 
 +*/ 
 + 
 +var_export([1, 2, 3], false, VAR_EXPORT_SHORT_ARRAY | VAR_EXPORT_NO_INDEX | VAR_EXPORT_COMPACT); 
 +/* 
 +[1, 2, 3] 
 +*/ 
 +</code> 
 + 
 +===== Backward Incompatible Changes ===== 
 +There shouldn'be any backwards incompatible changes as ''var_export()'' will continue to produce valid PHP code such that ''var_export()'' to PHP and PHP back to ''var_export()'' will continue to work as expected. The syntax changes are all forwards compatible as of PHP 5.4 so we shouldn't see any issues here.
  
 ===== Proposed PHP Version(s) ===== ===== Proposed PHP Version(s) =====
Line 110: Line 172:
  
 https://news-web.php.net/php.internals/109415 https://news-web.php.net/php.internals/109415
 +
 +https://externals.io/message/109415#109415
  
 ===== Rejected Features ===== ===== Rejected Features =====
  
rfc/var-export-array-syntax.1585584140.txt.gz · Last modified: 2020/03/30 16:02 by googleguy