# RFC: Property get/set syntax - Thread: https://externals.io/message/60222 - Original archive: https://news-web.php.net/php.internals/60222 - Started by Clint M Priest on 2012-04-20T02:10:48+00:00 - Messages: 12 - 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 --- ## #60222 — Clint M Priest — 2012-04-20T02:10:48+00:00 URL: https://externals.io/message/60222#60222 The only "open comments" I have on this project is the "read-only" and "write-only" keywords. Are the dashes acceptable or undesirable? write-only was not in the original RFC but made sense to have the alternate to read-only, any objections? If there is no other discussion for this, I'd like to move this to the voting phase, any objects? https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented -Clint --- ## #60225 — Stas Malyshev — 2012-04-20T06:32:49+00:00 URL: https://externals.io/message/60222#60225 · In reply to: #60222 Hi! > If there is no other discussion for this, I'd like to move this to the voting phase, any objects? > > https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented Sorry, I didn't have time to look into it yet (yes I know it was around for a long time...) in detail. From the quick glance I don't like the read-only/write-only keywords too much but maybe it's ok. It's not clear what "automatic implementation" is. Could you expand this section and add explanation what actually happens? What would happen if I use $this->property &= $a; or $a &= $this->property; $a = 1;? What happens if getter/setter function uses the same property it is defined for? What if it uses other property that in turn uses this one? In the last example for overloading, it looks like "parent::$Milliseconds = $value;" calls parent setter. This looks like static property access but is not. I don't think it's a good thing. What if you also have static class var called $Milliseconds? And especially that later you introduce the same syntax for accessing class properties! How these would work with isset - what !empty($this->Hours) return? What would happen if you do unset($this->Hours)? What happens if you do $this->Hours++ or sort($this->Hours) (assuming $Hours is an array)? These things need to be defined in the RFC too. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #60227 — Christoph Hochstrasser — 2012-04-20T07:29:16+00:00 URL: https://externals.io/message/60222#60227 · In reply to: #60222 Hi, > Are the dashes acceptable or undesirable? I think without dashes it is more in line with other keywords, like "instanceof" or "insteadof". Because keywords are not case sensitive, one who likes them to be more readable could write them camelCased, for example "readOnly", or "writeOnly". -- Christoph Hochstrasser http://twitter.com/hochchristoph | http://christophh.net | https://github.com/CHH --- ## #60229 — Patrick ALLAERT — 2012-04-20T10:35:32+00:00 URL: https://externals.io/message/60222#60229 · In reply to: #60225 2012/4/20 Stas Malyshev : > How these would work with isset - what !empty($this->Hours) return? What > would happen if you do unset($this->Hours)? What happens if you do > $this->Hours++ or sort($this->Hours) (assuming $Hours is an array)? > These things need to be defined in the RFC too. My suggestion is to support the same methods for properties as we do for magic class methods: __set, __get, __isset and __unset. All the other operations (sort, ++, <<,...) should behave exactly as if it was be implemented with current magic class methods with a usual switch/case statement. --- ## #60230 — Matthew Weier O'Phinney — 2012-04-20T13:13:47+00:00 URL: https://externals.io/message/60222#60230 · In reply to: #60227 > Hi, > > […] > > I think without dashes it is more in line with other keywords, like > "instanceof" or "insteadof". > > Because keywords are not case sensitive, one who likes them to be more > readable could write them camelCased, for example "readOnly", or > "writeOnly". If they are to be keywords, I'd argue we should use the dash variant -- the reason being that with the dash, there can be no conflict with existing constant, variable, or function names. I know I've had a fair number of each named both "readonly" and "writeonly". -- Matthew Weier O'Phinney Project Lead | matthew@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc --- ## #60253 — Clint M Priest — 2012-04-21T23:55:12+00:00 URL: https://externals.io/message/60222#60253 · In reply to: #60229 isset/unset property hooks I could definitely see having the isset and unset hooks as well, anyone disagree with that? I would expect them to syntactically show up as such: public $Hours { get { ... } set { ... } isset { return true; /* returns bool */ } unset { unset(...); /* returns void */ } } Thoughts? Operators I've tested with a number of the operators and they are all working as expected. I have updated the RFC to reflect that. I will also write tests for reference access as well as with some functions such as `sort()`, is_*(), empty() and some others. Other suggestions on functions we should write tests for? read-only/write-only There are people on both sides of the fence, where do I go from here, put it up for a specific vote? parent∷ scope access For the parent::$Milliseconds comment by Stanislav. This was in the original RFC and I think it fits well since it's the same syntax that would be used in a function to access a parent function, such as function a() { /* ... */ return parent::a(); } Though I have not used the parent::$xxx to access static values myself I know it's possible. Right now using parent:: format would first look for a parent accessor, then a parent static accessor, then would follow normal functionality, to access a parent static reference. I've documented this in the RFC under Overloading Properties now. What other format/keyword would make as much sense as parent::? -Clint -----Original Message----- From: patrick.allaert@gmail.com [mailto:patrick.allaert@gmail.com] On Behalf Of Patrick ALLAERT Sent: Friday, April 20, 2012 5:36 AM To: Stas Malyshev Cc: Clint M Priest; internals@lists.php.net Subject: Re: [PHP-DEV] RFC: Property get/set syntax 2012/4/20 Stas Malyshev >: > How these would work with isset - what !empty($this->Hours) return? > What would happen if you do unset($this->Hours)? What happens if you > do $this->Hours++ or sort($this->Hours) (assuming $Hours is an array)? > These things need to be defined in the RFC too. My suggestion is to support the same methods for properties as we do for magic class methods: __set, __get, __isset and __unset. All the other operations (sort, ++, <<,...) should behave exactly as if it was be implemented with current magic class methods with a usual switch/case statement. --- ## #60254 — Clint M Priest — 2012-04-22T02:36:05+00:00 URL: https://externals.io/message/60222#60254 · In reply to: #60225 > How these would work with isset - what !empty($this->Hours) return? What would happen if you do unset($this->Hours)? What happens if you do $this->Hours++ or sort($this->Hours) (assuming $Hours is an array)? > These things need to be defined in the RFC too. So I've just tested these things and the accessors perform the same way as with __get()/__set(). empty() - Returns true for a property retrieved via __get() or via a getter -- Any idea why this would be the case for __get()? Is this a bug? unset() - Would unset a temporary variable (the one returned by the getter) -- see previous email re: adding unset/isset property functions. `sort()` - Does the same thing as with __get()/__set() which is to say, the array is sorted but the property is not updated with the value. Should accessor behave differently than the magic methods? Should this just be documents or should this be fixed? -Clint --- ## #60255 — Stas Malyshev — 2012-04-22T03:33:20+00:00 URL: https://externals.io/message/60222#60255 · In reply to: #60254 Hi! > empty() - Returns true for a property retrieved via __get() or via a > getter -- Any idea why this would be the case for __get()? Is this a > bug? isset() calls __isset(), empty() calls __isset() and __get(). I'm not sure what exactly you consider to be a bug. > unset() - Would unset a temporary variable (the one returned by the > getter) -- see previous email re: adding unset/isset property > functions. unset() calls __unset(). > `sort()` - Does the same thing as with __get()/__set() which is to say, > the array is sorted but the property is not updated with the value. > Should accessor behave differently than the magic methods? Should > this just be documents or should this be fixed? `sort()` works just fine if you define __get to return by-ref. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #60256 — Clint M Priest — 2012-04-22T03:48:27+00:00 URL: https://externals.io/message/60222#60256 · In reply to: #60255 > -----Original Message----- > From: Stas Malyshev [mailto:smalyshev@sugarcrm.com] > Sent: Saturday, April 21, 2012 10:33 PM > To: Clint M Priest > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] RFC: Property get/set syntax > > Hi! > > > […] > > isset() calls __isset(), empty() calls __isset() and __get(). I'm not sure what exactly you consider to be a bug. I see, well the only way to resolve this would be to add isset and unset property functions as well. Anyone against it? > > > […] > > unset() calls __unset(). > > > […] > > `sort()` works just fine if you define __get to return by-ref. Returning by reference was not documented in the original RFC, would this syntax work for everyone? public $Hours { &get { return $this->a; } } > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 --- ## #61019 — Benjamin Eberlei — 2012-06-28T09:54:36+00:00 URL: https://externals.io/message/60222#61019 · In reply to: #60256 What is the state here with regard to merge into php-src? > > > > […] > sure what exactly you consider to be a bug. > > I see, well the only way to resolve this would be to add isset and unset > property functions as well. > > Anyone against it? > > > […] > > Returning by reference was not documented in the original RFC, would this > syntax work for everyone? > > public $Hours { > &get { return $this->a; } > } > > > […] --- ## #61114 — Clint Priest — 2012-07-09T02:46:40+00:00 URL: https://externals.io/message/60222#61114 · In reply to: #61019 I've just recently had my second child and closed on a new house, so been a bit busy. I'll be working to finish up what's left in the coming weeks. Right now I'm told there are some conflicts with a merge from master that I have to resolve, then the fork will be ready for playing around with. Hopefully I'll have that fixed up later this week. From: Benjamin Eberlei [mailto:kontakt@beberlei.de] Sent: Thursday, June 28, 2012 4:55 AM To: Clint Priest Cc: Stas Malyshev; internals@lists.php.net Subject: Re: [PHP-DEV] RFC: Property get/set syntax What is the state here with regard to merge into php-src? > -----Original Message----- > From: Stas Malyshev [mailto:smalyshev@sugarcrm.com] > Sent: Saturday, April 21, 2012 10:33 PM > To: Clint M Priest > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] RFC: Property get/set syntax > > Hi! > > > […] > > isset() calls __isset(), empty() calls __isset() and __get(). I'm not sure what exactly you consider to be a bug. I see, well the only way to resolve this would be to add isset and unset property functions as well. Anyone against it? > > > […] > > unset() calls __unset(). > > > […] > > `sort()` works just fine if you define __get to return by-ref. Returning by reference was not documented in the original RFC, would this syntax work for everyone? public $Hours { &get { return $this->a; } } > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227parent = $this; $this->_children[$key] = $value; } offsetUnset { $value->parent = null; unset($this->_children[$key]; } // etc. } } $parent = new Parent(); $child = new Child(); $parent->children[] = $child; // $child->parent === $parent Cheers, Bernhard 2012/7/9 Clint Priest : > I've just recently had my second child and closed on a new house, so been a bit busy. I'll be working to finish up what's left in the coming weeks. > > Right now I'm told there are some conflicts with a merge from master that I have to resolve, then the fork will be ready for playing around with. Hopefully I'll have that fixed up later this week. > > From: Benjamin Eberlei [mailto:kontakt@beberlei.de] > Sent: Thursday, June 28, 2012 4:55 AM > To: Clint Priest > Cc: Stas Malyshev; internals@lists.php.net > Subject: Re: [PHP-DEV] RFC: Property get/set syntax > > What is the state here with regard to merge into php-src? > > > > > […] > I see, well the only way to resolve this would be to add isset and unset property functions as well. > > Anyone against it? > > > […] > Returning by reference was not documented in the original RFC, would this syntax work for everyone? > > public $Hours { > &get { return $this->a; } > } > > > […]