rfc:simplified_named_params

Differences

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

Link to this comparison view

Next revision		Previous revision
rfc:simplified_named_params [2016/01/18 22:38] – created mindplayrfc:simplified_named_params [2021/01/13 15:22] (current) – named_params has been accepted, so this RFC is obsolete cmb
Line 1: Line 1:
 ====== PHP RFC: Simplified Named Arguments ====== ====== PHP RFC: Simplified Named Arguments ======
-  * Version: 0.1+  * Version: 0.2
   * Date: 2016-01-18   * Date: 2016-01-18
   * Author: Rasmus Schultz <rasmus@mindplay.dk>   * Author: Rasmus Schultz <rasmus@mindplay.dk>
-  * Status: Draft+  * Status: Obsolete
   * First Published at: http://wiki.php.net/rfc/simplified_named_params   * First Published at: http://wiki.php.net/rfc/simplified_named_params
  
Line 94: Line 94:
 Instead, upon encountering an unmatched named argument, a useful error message will be generated by scanning upwards through any parent class/interface declarations to find and report any possible inconsistencies - in the example above, the addition to the error message would be e.g. ''parameter names of method Counter::count() do not match those of CounterInterface::count()''. Instead, upon encountering an unmatched named argument, a useful error message will be generated by scanning upwards through any parent class/interface declarations to find and report any possible inconsistencies - in the example above, the addition to the error message would be e.g. ''parameter names of method Counter::count() do not match those of CounterInterface::count()''.
  
-Although this causes potential problems with named arguments applied to existing code, the problem is considered minor, since most existing code does not use long argument lists intended to be called using named arguments - most existing code with many options, for lack of better, likely uses a ''$options'' array argument, and uses code to explicitly unpack and apply the options. (The "Non-Features" section discusses this further.)+Although this causes potential problems with named arguments applied to existing code, the problem is considered minor, since most existing code does not use long argument lists intended to be called using named arguments - most existing code with many options, for lack of better, likely uses a ''$options'' array argument, and uses code to explicitly unpack and apply the options. (This is discussed further in the section "Differences from Previous Proposal", below.) 
 + 
 +==== Magic Methods ==== 
 + 
 +Named arguments, are not applicable to magic methods implemented via ''__call()'' or ''__callStatic()'' - per this proposal, named arguments can only be matched to parameters that actually have names; parameters passed dynamically via these magic methods have only numeric indices. 
 + 
 +As for implementations of ''__invoke()'', these have actual argument lists, and therefore can be invoked using named arguments.
  
 ==== Impact on Reflection ==== ==== Impact on Reflection ====
Line 100: Line 106:
 This proposal has no impact on reflection. This proposal has no impact on reflection.
  
-===== Differences from Existing Proposal =====+===== Differences from Previous Proposal =====
  
 Since this is a simplified proposal, compared to the one previously proposed by Nikita Popov, the following section will cover non-features and differences of this proposal as compared to that. Since this is a simplified proposal, compared to the one previously proposed by Nikita Popov, the following section will cover non-features and differences of this proposal as compared to that.
Line 185: Line 191:
  
 Dealing with these issues when using open sets of options, passed via arrays, is an issue you deliberately elect to deal with - the principle behind this RFC, is that named arguments must map strictly to declared parameters, otherwise you might as well be using a single array of options as the only argument. Dealing with these issues when using open sets of options, passed via arrays, is an issue you deliberately elect to deal with - the principle behind this RFC, is that named arguments must map strictly to declared parameters, otherwise you might as well be using a single array of options as the only argument.
 +
 +===== Notes on Syntax =====
 +
 +The proposed syntax resembles that of object literals in JS, and conflicts with an [[https://wiki.php.net/rfc/objectarrayliterals|inactive RFC]] written in 2011. It does not appear to conflict with another [[https://wiki.php.net/rfc/bare_name_array_literal|declined RFC]] written in 2014, which proposed something similar for arrays rather than ''stdClass'' objects.
 +
 +Regarding potential confusion over similarity to object literals in JS, curly braces are widely used in various languages to delimit the start and end of functions, conditional blocks, object literals, etc. - and arrays in PHP are probably closer in nature to JS objects than ''stdClass'' is, for example ''$o['k'] = 'v';'' does not work on ''stdClass'' in PHP, but does work on arrays, which have a different syntax from JS object literals, as observed by the 2014 array literals proposal mentioned above, which proposes to build on PHP arrays, and array syntax, not on JS object literal syntax, although it makes clear the intended end is something similar to JS object literals.
 +
 +If implemented, this RFC would stand in the way of adopting a JS-like syntax for object literals, but does not stand in the way of something else providing the same utility for arrays, which generally see more use and have greater utility than ''stdClass'', due to the greater number of array functions, operators, and other features.
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
rfc/simplified_named_params.1453156696.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools