# Patch: getters/setters syntax Implementation - Thread: https://externals.io/message/56785 - Original archive: https://news-web.php.net/php.internals/56785 - Started by Rasmus Schultz on 2011-12-05T23:10:58+00:00 - Messages: 14 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #56785 — Rasmus Schultz — 2011-12-05T23:10:58+00:00 URL: https://externals.io/message/56785#56785 2011/12/4 Clint M Priest : > Updated patch w/o white-space: http://www.clintpriest.com/patches/accessors_v1.patch > > In the end it is a relatively simple patch. The new syntax effectively creates internal functions on the object and the system looks for those functions and calls them at the appropriate time. > > Example: > class z { > public $Hours { > public get { return $this->_Hours; } > protected set { $this->_Hours = $value; } > } > } > > Defines: > $o->__getHours(); > $o->__setHours($value); You forgot to declare the backing field z::$_Hours in this example. From a semantic point of view, I find it misleading to first declare $Hours as public, then lowering the bar by making the set-accessor protected. The most common use-case for accessors is public - so I would suggest a syntax more along the lines of this: class z { private $_hours; get $hours { // accessor is public by default return $this->_hours; } protected set $hours { $this->_hours = $hours; // local variable $hours is the new value } } And perhaps a short form for added convenience, where the backing-field is automatically added for you - e.g.: class z { get $hours { // accessor is public by default return $value; // $value provides access to the backing field (same way $this provides access to the object context) } protected set $hours { $value = $hours; // local variable $hours is the new value, $value references the backing field } } thoughts? --- ## #56787 — Clint M Priest — 2011-12-06T03:23:52+00:00 URL: https://externals.io/message/56785#56787 · In reply to: #56785 I believe the attempt with the RFC was to mimic the syntax that C# went with, the RFC is here: https://wiki.php.net/rfc/propertygetsetsyntax The first public would apply to either of the get/set which did not have it further defined, for example: public $Hours { get { ... } private set { ... } } Also, with automatic implementations (at present) the parent access level controls the automatic property generation: private $Hours { public get; public set; } Would define an internal variable of $__Hours as private. Perhaps it should always be a private internal variable, it was not designated in the rfc and I made it this way to be the most flexible for the author. -----Original Message----- From: Rasmus Schultz [mailto:rasmus@mindplay.dk] Sent: Monday, December 05, 2011 5:11 PM To: internals@lists.php.net Subject: [PHP-DEV] Re: Patch: getters/setters syntax Implementation 2011/12/4 Clint M Priest : > Updated patch w/o white-space: http://www.clintpriest.com/patches/accessors_v1.patch > > In the end it is a relatively simple patch. The new syntax > effectively creates internal functions on the object and the system looks for those functions and calls them at the appropriate time. > > Example: > class z { > public $Hours { > public get { return $this->_Hours; } > protected set { $this->_Hours = $value; } > } > } > > Defines: > $o->__getHours(); > $o->__setHours($value); You forgot to declare the backing field z::$_Hours in this example. From a semantic point of view, I find it misleading to first declare $Hours as public, then lowering the bar by making the set-accessor protected. The most common use-case for accessors is public - so I would suggest a syntax more along the lines of this: class z { private $_hours; get $hours { // accessor is public by default return $this->_hours; } protected set $hours { $this->_hours = $hours; // local variable $hours is the new value } } And perhaps a short form for added convenience, where the backing-field is automatically added for you - e.g.: class z { get $hours { // accessor is public by default return $value; // $value provides access to the backing field (same way $this provides access to the object context) } protected set $hours { $value = $hours; // local variable $hours is the new value, $value references the backing field } } thoughts? --- ## #56791 — Christian Kaps — 2011-12-06T08:45:07+00:00 URL: https://externals.io/message/56785#56791 · In reply to: #56787 Hi, I also find this syntax confusing and I think it has a huge WTF factor. Some thoughts about the syntax: - At the first glance, it isn't clear which visibility the getter or setter has - The extra indentation level makes the code more unreadable class Foo { /** * */ private $_bar; /** * */ public $bar{ /** * */ set { if ($bar) { $this->_bar = $bar * 12; } else { $this->_bar = 0 } } /** * */ private set { if ($this->_bar === null) { return 0; } return $this->_bar; } } /** * */ public function baz() { } } - What about type hints? I prefer a more AS3 like getter and setter syntax. http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f30.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7fcb Have you read my previous mail http://news.php.net/php.internals/56762. I think this syntax fits more to PHP because its similar to the already existing(magic) getter and setter syntax. What do you think? Christian Am 06.12.2011 04:23, schrieb Clint M Priest: > I believe the attempt with the RFC was to mimic the syntax that C# > went with, the RFC is here: > https://wiki.php.net/rfc/propertygetsetsyntax > > The first public would apply to either of the get/set which did not > have it further defined, for example: > > public $Hours { > get { ... } > private set { ... } > } > > Also, with automatic implementations (at present) the parent access > level controls the automatic property generation: > > private $Hours { > public get; > public set; > } > > Would define an internal variable of $__Hours as private. Perhaps it > should always be a private internal variable, it was not designated > in > the rfc and I made it this way to be the most flexible for the > author. > > -----Original Message----- > From: Rasmus Schultz [mailto:rasmus@mindplay.dk] > Sent: Monday, December 05, 2011 5:11 PM > To: internals@lists.php.net > Subject: [PHP-DEV] Re: Patch: getters/setters syntax Implementation > > 2011/12/4 Clint M Priest : > > […] > http://www.clintpriest.com/patches/accessors_v1.patch > > […] > creates internal functions on the object and the system looks for > those functions and calls them at the appropriate time. > > […] > > You forgot to declare the backing field z::$_Hours in this example. > > From a semantic point of view, I find it misleading to first declare > $Hours as public, then lowering the bar by making the set-accessor > protected. > > The most common use-case for accessors is public - so I would suggest > a syntax more along the lines of this: > > class z { > private $_hours; > > get $hours { // accessor is public by default > return $this->_hours; > } > > protected set $hours { > $this->_hours = $hours; // local variable $hours is the new value > } > } > > And perhaps a short form for added convenience, where the > backing-field is automatically added for you - e.g.: > > class z { > get $hours { // accessor is public by default > return $value; // $value provides access to the backing field > (same way $this provides access to the object context) > } > > protected set $hours { > $value = $hours; // local variable $hours is the new value, > $value references the backing field > } > } > > thoughts? --- ## #56798 — Pierre Joye — 2011-12-06T11:46:36+00:00 URL: https://externals.io/message/56785#56798 · In reply to: #56787 > I believe the attempt with the RFC was to mimic the syntax that C# went with, the RFC is here: https://wiki.php.net/rfc/propertygetsetsyntax C# like setter/getter is definitely what I would like to have in PHP, it is a very clear and known syntax, while being features rich. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #56802 — Rasmus Schultz — 2011-12-06T13:58:24+00:00 URL: https://externals.io/message/56785#56802 · In reply to: #56791 On Tue, Dec 6, 2011 at 3:45 AM, Christian Kaps wrote: > Hi, > > I also find this syntax confusing and I think it has a huge WTF factor. > > Some thoughts about the syntax: > - At the first glance, it isn't clear which visibility the getter or > setter has > - The extra indentation level makes the code more unreadable > > class Foo { > > /** > * > */ > private $_bar; > > /** > * > */ > public $bar{ > > /** > * > */ > set { > if ($bar) { > $this->_bar = $bar * 12; > } else { > $this->_bar = 0 > } > } > > /** > * > */ > private set { > if ($this->_bar === null) { > return 0; > } > > return $this->_bar; > } > } > > /** > * > */ > public function baz() { > > } > } > > - What about type hints? > > I prefer a more AS3 like getter and setter syntax. > http://help.adobe.com/en_US/**ActionScript/3.0_**ProgrammingAS3/** > WS5b3ccc516d4fbf351e63e3d118a9**b90204-7f30.html#** > WS5b3ccc516d4fbf351e63e3d118a9**b90204-7fcb > > Have you read my previous mail http://news.php.net/php.**internals/56762 > . > I think this syntax fits more to PHP because its similar to the already > existing(magic) getter and setter syntax. > > What do you think? > > Christian > I agree with all of those points - the extra indentation looks messy, and yes, type hints are important. It does fit better with PHP in general. It would be nice to also have support for automatic backing fields in addition though - so something simple like this: class BlogPost { private $_author; public get author() { return $this->_author; } public set author(Person $value) { $this->_author = $value; } } Could be written like this: class BlogPost { public Person $author; } Effectively, this shorthand syntax just gives you type-safe properties - but it refactors nicely, since you can replace it with a full implementation of a backing field at any point. (on second thought, I don't like the idea I suggested before - adding a magical $value in accessors, similar to $this - it's confusing and it's going to look like an undeclared local variable...) --- ## #56804 — Clint M Priest — 2011-12-06T14:14:21+00:00 URL: https://externals.io/message/56785#56804 · In reply to: #56798 I prefer C# syntax myself but thinking about it, supporting both syntax's would be fairly trivial to add... Thoughts on that? -----Original Message----- From: Pierre Joye [mailto:pierre.php@gmail.com] Sent: Tuesday, December 06, 2011 5:47 AM To: Clint M Priest Cc: Rasmus Schultz; internals@lists.php.net Subject: Re: [PHP-DEV] Re: Patch: getters/setters syntax Implementation > I believe the attempt with the RFC was to mimic the syntax that C# > went with, the RFC is here: > https://wiki.php.net/rfc/propertygetsetsyntax C# like setter/getter is definitely what I would like to have in PHP, it is a very clear and known syntax, while being features rich. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #56805 — Sebastian Krebs — 2011-12-06T14:15:45+00:00 URL: https://externals.io/message/56785#56805 · In reply to: #56802 Hi 2011/12/6 Rasmus Schultz > On Tue, Dec 6, 2011 at 3:45 AM, Christian Kaps > […] > > > […] > http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f30.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7fcb > > […] > > > […] > > I agree with all of those points - the extra indentation looks messy, and > yes, type hints are important. It does fit better with PHP in general. > > It would be nice to also have support for automatic backing fields in > addition though - so something simple like this: > > class BlogPost > { > private $_author; > > public get author() > { > return $this->_author; > } > > public set author(Person $value) > { > $this->_author = $value; > } > } > > Could be written like this: > > class BlogPost > { > public Person $author; > } > > Effectively, this shorthand syntax just gives you type-safe properties - > but it refactors nicely, since you can replace it with a full > implementation of a backing field at any point. > > (on second thought, I don't like the idea I suggested before - adding a > magical $value in accessors, similar to $this - it's confusing and it's > going to look like an undeclared local variable...) > Because it seems everybody throws in their preferred syntax :X class X { public $myProperty { /* public *inherited* */ set (AnotherClass $value) { // Value from "outside" return $value; // Set to property } private get (AnotherClass $value) { // Value from property (Maybe with typehint) return $value; // returns value to the caller } } /* = 'default value'; */; } * No _magic_ $value * Type-Hints * I think nearly no suprise, what happens here In my eyes the goal should be to _not_ separate a property from its accessor anymore, which disqualifies both of Rasmus Schultz suggestions. At least this is _the_ reason, why I want to see this RFC to be implemented. --- ## #56806 — Will Fitch — 2011-12-06T14:26:11+00:00 URL: https://externals.io/message/56785#56806 · In reply to: #56802 > On Tue, Dec 6, 2011 at 3:45 AM, Christian Kaps wrote: > > > […] > > I agree with all of those points - the extra indentation looks messy, and > yes, type hints are important. It does fit better with PHP in general. > > It would be nice to also have support for automatic backing fields in > addition though - so something simple like this: > > class BlogPost > { > private $_author; > > public get author() > { > return $this->_author; > } > > public set author(Person $value) > { > $this->_author = $value; > } > } I don't like this approach. All efforts (which I'm currently part of) to implement type hinting return values will be compromised. If you want to implement accessors, keep them within a syntax that makes sense. Personally, I support the C# style as much as possible. Methods are already overused for purposes they shouldn't be, so if we're attempting to get around __set/get, let's not replace them with more method implementations. > > Could be written like this: > > class BlogPost > { > public Person $author; > } > > Effectively, this shorthand syntax just gives you type-safe properties - > but it refactors nicely, since you can replace it with a full > implementation of a backing field at any point. > > (on second thought, I don't like the idea I suggested before - adding a > magical $value in accessors, similar to $this - it's confusing and it's > going to look like an undeclared local variable...) --- ## #56818 — Stas Malyshev — 2011-12-07T02:29:42+00:00 URL: https://externals.io/message/56785#56818 · In reply to: #56798 Hi! > I believe the attempt with the RFC was to mimic the syntax that C# > went with, the RFC is here: > https://wiki.php.net/rfc/propertygetsetsyntax Reading this RFC I notice it makes get/set keywords. This would lead to huge amount of breakage in existing code, so I strongly suggest to look for another way. For example, __get and __set... I'm also not a big fan of magic $value variable coming from nowhere and function syntax without function definition. What if you want a getter to return by-reference? Or setter to get parameter by reference? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #56819 — Nikita Popov — 2011-12-07T06:17:15+00:00 URL: https://externals.io/message/56785#56819 · In reply to: #56818 The implementation specifically didn't introduce T_GET/T_SET on the lexer side and instead checks for T_STRINGs with content "get" or "set". Nikita > Hi! > > > > […] > > > Reading this RFC I notice it makes get/set keywords. This would lead to > huge amount of breakage in existing code, so I strongly suggest to look > for another way. For example, __get and __set... > > I'm also not a big fan of magic $value variable coming from nowhere and > function syntax without function definition. What if you want a getter to > return by-reference? Or setter to get parameter by reference? > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 --- ## #56836 — Rasmus Schultz — 2011-12-07T17:50:14+00:00 URL: https://externals.io/message/56785#56836 · In reply to: #56806 > if we're attempting to get around __set/get, let's not replace them with more method implementations I don't understand this argument. Accessors are methods - making them look like something else won't change that fact. In C#, type-hinted properties with automatic getters/setters actually compile down to two method implementations, while implemented getters/settings do the same, substituting "value" for whatever is required to access the auto-implemented backing field. > > > > > […] > > I don't like this approach. All efforts (which I'm currently part of) to > implement type hinting return values will be compromised. If you want to > implement accessors, keep them within a syntax that makes sense. > Personally, I support the C# style as much as possible. Methods are > already overused for purposes they shouldn't be, so if we're attempting to > get around __set/get, let's not replace them with more method > implementations. --- ## #56837 — Will Fitch — 2011-12-07T18:11:06+00:00 URL: https://externals.io/message/56785#56837 · In reply to: #56836 The difference being *where* the functionality gets mapped. It's not about making something "look like something else", it's about requiring more userspace definitions. Functionality within get {} and set {} can (and should IMO) be implemented outside of userspace code. Whether that means another union within op_array or a completely new structure mapped to a property zval and bitmap added to the zend_uchar type identifying it as an accessor.... I'm saying be creative - don't just implement something halfway for the sake of getting it done. > > […] > more method implementations > > I don't understand this argument. Accessors are methods - making them look > like something else won't change that fact. > > In C#, type-hinted properties with automatic getters/setters actually > compile down to two method implementations, while implemented > getters/settings do the same, substituting "value" for whatever is required > to access the auto-implemented backing field. > > > > > > […] --- ## #56838 — Rasmus Schultz — 2011-12-07T18:33:41+00:00 URL: https://externals.io/message/56785#56838 · In reply to: #56837 I have no opinion about how it gets implemented under the hood - I thought we were just discussing the syntax. I most likely don't know enough about the innards of PHP it carry on that discussion. But by userspace definitions, are you referring to the fact that getters and setters would compile down to actual methods? I have no strong feelings about that one way or the other - as long as the reflection API reports what was defined in the source code, rather than reflecting the underlying accessor-methods as actual methods. (something that doesn't seem to be true for traits...) I don't know if that's meaningful or relevant to you, but I think that's all I can contribute to that discussion... > The difference being *where* the functionality gets mapped. It's not > about making something "look like something else", it's about requiring > more userspace definitions. Functionality within get {} and set {} can > (and should IMO) be implemented outside of userspace code. Whether that > means another union within op_array or a completely new structure mapped to > a property zval and bitmap added to the zend_uchar type identifying it as > an accessor.... I'm saying be creative - don't just implement something > halfway for the sake of getting it done. > > > > > > […] > look > > […] > required > > […] > and > > […] > to > > […] > to > > […] > to > > […] --- ## #56840 — Will Fitch — 2011-12-07T18:58:01+00:00 URL: https://externals.io/message/56785#56840 · In reply to: #56838 I'm saying that when you define an accessor, the body of the get/set functionality is contained within get {} and set {}, just like C#. I'm referencing your suggestion to automatic backing fields. There's no need for the backup. Reflection for accessors should be treated the same as the rest. Since there is a definition for each get and set, Reflection{Property/Accessor} should treat invocations of those separately, so I agree with that, but Reflection hasn't failed us so far. :) > I have no opinion about how it gets implemented under the hood - I thought > we were just discussing the syntax. I most likely don't know enough about > the innards of PHP it carry on that discussion. > > But by userspace definitions, are you referring to the fact that getters > and setters would compile down to actual methods? I have no strong feelings > about that one way or the other - as long as the reflection API reports > what was defined in the source code, rather than reflecting the underlying > accessor-methods as actual methods. (something that doesn't seem to be true > for traits...) > > I don't know if that's meaningful or relevant to you, but I think that's > all I can contribute to that discussion... > > > > > […]