RE: [PHP-DEV] RFC: Property get/set syntax

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 <smalyshev@sugarcrm.com<mailto:smalyshev@sugarcrm.com>>: > 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.