rfc:propertygetsetsyntax-alternative-typehinting-syntax
no way to compare when less than two revisions
Differences
This shows you the differences between two versions of the page.
Next revision | |||
— | rfc:propertygetsetsyntax-alternative-typehinting-syntax [2013/01/04 14:16] – created nikic | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Request for Comments: Alternative typehinting syntax for accessors ====== | ||
+ | * Date: 2013-01-04 | ||
+ | * Author: Nikita Popov < | ||
+ | * Status: Under Discussion | ||
+ | ===== Introduction ===== | ||
+ | |||
+ | This RFC proposes a different typehinting syntax for the [[https:// | ||
+ | |||
+ | ===== Current syntax(es) ===== | ||
+ | |||
+ | The current accessors RFC implements two syntax variations for accessors. The first is the original parentheses-less form using the magic '' | ||
+ | |||
+ | <code php> | ||
+ | private $seconds; | ||
+ | public $hours { | ||
+ | get { return $this-> | ||
+ | set { $this-> | ||
+ | } | ||
+ | </ | ||
+ | | ||
+ | The newly added second syntax allows specifying the accessors in a more function-like form: | ||
+ | |||
+ | <code php> | ||
+ | private $seconds; | ||
+ | public $hours { | ||
+ | get() { return $this-> | ||
+ | set($hours) { $this-> | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | One of the reasons to add the latter syntax is to allow typehinting the setter. E.g. this allows to do something like the following: | ||
+ | |||
+ | <code php> | ||
+ | public $date { | ||
+ | get() { return $this-> | ||
+ | set(DateTime $date) { $this-> | ||
+ | } | ||
+ | </ | ||
+ | | ||
+ | The '' | ||
+ | |||
+ | <code php> | ||
+ | public $date { | ||
+ | get; | ||
+ | set(DateTime $date); | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | ===== Typehinting ===== | ||
+ | |||
+ | There is clear evidence that typehinting is of great importance to PHP developers. This doesn' | ||
+ | |||
+ | Thus the main objective of this proposal is to improve the typehinting aspect of the accessors proposal. | ||
+ | |||
+ | ===== Proposed syntax ===== | ||
+ | |||
+ | This RFC proposes to change the current syntax for typehinted accessors... | ||
+ | |||
+ | <code php> | ||
+ | public $date { | ||
+ | get() { return $this-> | ||
+ | set(DateTime $date) { $this-> | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | ... by moving the typehint in front of the property name: | ||
+ | |||
+ | <code php> | ||
+ | public DateTime $date { | ||
+ | get { return $this-> | ||
+ | set { $this-> | ||
+ | } | ||
+ | </ | ||
+ | | ||
+ | Automatic accessors can be used to reduce the boilerplate: | ||
+ | |||
+ | <code php> | ||
+ | public DateTime $date { get; set; } | ||
+ | </ | ||
+ | | ||
+ | Which again is equivalent to just the property with the typehint: | ||
+ | |||
+ | <code php> | ||
+ | public DateTime $date; | ||
+ | </ | ||
+ | |||
+ | ===== 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 '' | ||
+ | |||
+ | 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 '' | ||
+ | |||
+ | <code php> | ||
+ | public $date { // <-- This is important | ||
+ | get { | ||
+ | // Some | ||
+ | // Rather | ||
+ | // Long | ||
+ | // Code | ||
+ | } | ||
+ | set(DateTime $date) { // <-- And the typehint here is important, too | ||
+ | // Some | ||
+ | // Further | ||
+ | // Code | ||
+ | // Here | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | Another benefit I see in this typehint syntax is that most programmers are already **familiar** with it, because virtually every strongly typed language uses it. Most dynamic languages with support for optional typing that I know (like Dart or TypeScript) also use this syntax. This makes the syntax a lot more intuitive. If you want to typehint a property your first try will probably be putting the typename in front of it, rather than coming up with something like '' | ||
+ | |||
+ | One last benefit that comes from this syntax is that we no longer need two ways to specify accessors (with and without parentheses). Though I also heard the opinion from some people that both syntaxes should be still kept to avoid the '' | ||
+ | |||
+ | ===== Common Misconceptions ===== | ||
+ | |||
+ | When I brought this up last time the discussion showed some misconceptions regarding this proposal. This seems to be inherent to any discussion involving typehints in some way, so I decided to clear some things up beforehand. | ||
+ | |||
+ | The important thing to realize is that this proposal does **not add new typehinting concepts** to PHP. It's just suggests a more general, more convenient and more familiar syntax for what already exists in the accessors proposal. The '' | ||
+ | |||
+ | <code php> | ||
+ | public $date { | ||
+ | get; | ||
+ | set(DateTime $date); | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | The last time I brought this up most of the discussion focused on the question whether typehints in PHP are a good idea in general and I would like to prevent this kind of discussion this time, as it is only tangentially related. Fact is that we do have typehints for methods and that those typehints are used a lot. Fact is that the typehints are also used a lot on accessors (30%) and often *just* for the typehint (15%). Fact also is that the accessors proposal makes the normal method typehints apply to properties. So the question really isn't whether typehints on properties are a good idea, the question is rather whether we want to have the convoluted '' | ||
+ | |||
+ | I understand that some people on internals disapprove of typehints in general and that they have reasons to do so. I hope that those people will be able to consider this without prejudice and on its actual merits concerning the actual use of the language. Thanks. | ||
+ | |||
+ | ===== Patch ===== | ||
+ | |||
+ | I haven' |
rfc/propertygetsetsyntax-alternative-typehinting-syntax.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1