rfc:propertygetsetsyntax-alternative-typehinting-syntax

Differences

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

Link to this comparison view

Next revision		Previous revision
rfc:propertygetsetsyntax-alternative-typehinting-syntax [2013/01/04 14:16] – created nikicrfc:propertygetsetsyntax-alternative-typehinting-syntax [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 2: Line 2:
   * Date: 2013-01-04   * Date: 2013-01-04
   * Author: Nikita Popov <nikic@php.net>   * Author: Nikita Popov <nikic@php.net>
-  * Status: Under Discussion+  * Status: Declined
  
 ===== Introduction ===== ===== Introduction =====
Line 84: Line 84:
 <code php> <code php>
 public DateTime $date; public DateTime $date;
 +</code>
 +
 +===== Default values and nullability =====
 +
 +When the shorthand ''public Type $name;'' syntax is used it will be possible to specify a default value (something that is not normally possible with accessors). The default value will use the same syntax and semantics as function parameter typehints. For example the following specifies an ''array'' property with an array default value:
 +
 +<code php>
 +public array $foo = [1, 2, 3];
 +</code>
 +
 +The nullability semantics are also the same as with parameter typehints:
 +
 +<code php>
 +public DateTime $date;        // can not assign null
 +public DateTime $date = null; // can assign null
 +</code>
 +
 +Note that properties are ''null'' initialized by default. The nullability semantics do not (and can not) affect this. They only specify whether it's possible to **assign** ''null'' to the property after initialization.
 +
 +Default values can only be used on the shorthand notation. If accessor methods are specified a default value can not be used. The only exception is the ''= null'' default, which can still be used to specify nullability:
 +
 +<code php>
 +public DateTime $date = null {
 +    get { ... } set { ... }
 +}
 </code> </code>
  
 ===== Benefits of the proposed syntax ===== ===== Benefits of the proposed syntax =====
  
-The proposed syntax has several benefits over the current syntax, with the main one being that it **optimizes a very common use case** (while not making other use cases worse). As mentioned above about 15% of all accessor methods in Symfony would be able to use the ''public DateTime $date'' style shorthand notation.+The proposed syntax has several benefits over the current syntax, with the main one being that it **optimizes a very common use case** (while not making other use cases worse). As mentioned above about 15% of all accessor methods in Symfony would be able to use the ''public DateTime $date'' style shorthand notation. Furthermore this proposal allows a **default value** to be specified for typehinted properties.
  
 Even when the shorthand can not be used (because one actually defines some accessors) I would argue that the proposed syntax is more elegant than the current one, mainly because the **relevant API information is focused** at one point at the start of the declaration. For interacting with the class only the visibility and the typehint are of importance, whereas the actual implementation is irrelevant. The ''public DateTime $date { ... }'' syntax does a better job at conveying the relevant bits than the current syntax: Even when the shorthand can not be used (because one actually defines some accessors) I would argue that the proposed syntax is more elegant than the current one, mainly because the **relevant API information is focused** at one point at the start of the declaration. For interacting with the class only the visibility and the typehint are of importance, whereas the actual implementation is irrelevant. The ''public DateTime $date { ... }'' syntax does a better job at conveying the relevant bits than the current syntax:
Line 132: Line 157:
 ===== Patch ===== ===== Patch =====
  
-I haven't written a patch for this yet, but the change from the current syntax to this one is rather simple. The current accessors proposal will need special handling of the typehint in any case (it can't be handled as a normal method typehint). The proposed syntax would actually make the handling slightly simpler.+The patch for this proposal is available here: https://gist.github.com/4579298. You can find the individual commits here: https://github.com/nikic/php-src/commits/alternativeSyntax. 
 + 
 +===== Voting ===== 
 + 
 +This proposal depends on the main accessors RFC. The result of this vote is only relevant if the main RFC is accepted. As this is a language change it requires a 2/3 majority. 
 + 
 +<doodle title="Should the proposed typehinting syntax be used instead of the current one?" auth="nikic" voteType="single" closed="true"> 
 +   * Yes 
 +   * No 
 +</doodle> 
 + 
 +The vote ended 3 in favor, 12 against, as such this feature is declined.
rfc/propertygetsetsyntax-alternative-typehinting-syntax.1357309018.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools