Re: [PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing
Hi! Sorry I guess I should have been more clear. The recursion would prevent the accessor from being called which would allow the ordinary property code to execute, thus accessing the property directly. I This could lead to weird scenarios where the same $foo-bar in random function could call or not call an accessor depending on the stack trace (provided that accessors call out to other functions - which is not frequent but can definitely happen). In case of __get it's harmless since we know $foo-bar doesn't exist anyway, but if we do allow $bar to exist in $foo it might get weird. I'd certainly appreciate some notice/E_STRICT if this happens. Maybe I'd go even as far as issuing E_STRICT on having both $bar and any of the accessors for $bar in the same class - but this of course would scream on the scenario of augmenting existing $bar with accessors - which is legit, unless it gets weird as described above. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing
Well I guess this and many of the other issues from other threads are the reasons I had it written the way that it is currently (basically an extension of __get()) but numerous other proposals have muddied the situation. On Sunday, October 28, 2012 2:17:47 AM, Stas Malyshev wrote: Hi! Sorry I guess I should have been more clear. The recursion would prevent the accessor from being called which would allow the ordinary property code to execute, thus accessing the property directly. I This could lead to weird scenarios where the same $foo-bar in random function could call or not call an accessor depending on the stack trace (provided that accessors call out to other functions - which is not frequent but can definitely happen). In case of __get it's harmless since we know $foo-bar doesn't exist anyway, but if we do allow $bar to exist in $foo it might get weird. I'd certainly appreciate some notice/E_STRICT if this happens. Maybe I'd go even as far as issuing E_STRICT on having both $bar and any of the accessors for $bar in the same class - but this of course would scream on the scenario of augmenting existing $bar with accessors - which is legit, unless it gets weird as described above. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing
Recursion is guarded by the same mechanism __get uses to avoid recursion. On 10/26/2012 9:33 AM, Stas Malyshev wrote: Hi! v1.2 Proposes that this be inverted such that if there is an accessor defined for a given property name, the accessor will always be used. The accessor would be able to get/set/isset/unset the property with the same name as the accessor. No direct access to the property would be allowed except from within the accessor. One of the deficiencies frequently mentioned for __get was what if I want to override access for existing variable? Given that, I think accessor priority is a good thing. Now, with direct access from within the accessor it may get a bit tricky, especially considering loops, etc. What would happen in the scenario of __getHours calling foo() which does return $this-Hours? Is __getHours called again? Is it a fatal error? Does it return undefined like __get does? v1.2 proposal seems to make the most sense however it would incur a slight (possibly *very* slight) performance penalty. It may be an extra hash lookup, but if we could probably add the existence of accessor (or maybe even pointer) into zend_property_info then we wouldn't need the second hash lookup probably. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing
Hi! Recursion is guarded by the same mechanism __get uses to avoid recursion. __get on recursion returns undefined, __set on recursion does nothing. However you're saying No direct access to the property would be allowed except from within the accessor - but what this not allowing means? Just returning undefined if __getHours was previously called? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing
Sorry I guess I should have been more clear. The recursion would prevent the accessor from being called which would allow the ordinary property code to execute, thus accessing the property directly. I suppose if it were in a setter and the property were not defined by the accessor then it would automagically create a public property, not that it would matter if accessors always shadowed properties because the access control of the accessor would still prevail. But it could be written such that an accessor would define a private property upon set from within the setter. Recursion guarding in this case simply means that the get/set is guarded from being called more than once. It's the same mechanism that __get and __set use. On Saturday, October 27, 2012 3:20:38 PM, Stas Malyshev wrote: Hi! Recursion is guarded by the same mechanism __get uses to avoid recursion. __get on recursion returns undefined, __set on recursion does nothing. However you're saying No direct access to the property would be allowed except from within the accessor - but what this not allowing means? Just returning undefined if __getHours was previously called? -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing
Hi! v1.2 Proposes that this be inverted such that if there is an accessor defined for a given property name, the accessor will always be used. The accessor would be able to get/set/isset/unset the property with the same name as the accessor. No direct access to the property would be allowed except from within the accessor. One of the deficiencies frequently mentioned for __get was what if I want to override access for existing variable? Given that, I think accessor priority is a good thing. Now, with direct access from within the accessor it may get a bit tricky, especially considering loops, etc. What would happen in the scenario of __getHours calling foo() which does return $this-Hours? Is __getHours called again? Is it a fatal error? Does it return undefined like __get does? v1.2 proposal seems to make the most sense however it would incur a slight (possibly *very* slight) performance penalty. It may be an extra hash lookup, but if we could probably add the existence of accessor (or maybe even pointer) into zend_property_info then we wouldn't need the second hash lookup probably. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
