Re: [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
| From: | Clint Priest | Date: | Sun, 28 Oct 2012 00:42:01 +0000 |
| Subject: | Re: [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-63677@lists.php.net to get a copy of this message | ||
Sounds like you're implying that the mere existence of a properly named function such as __prop_get_hours() would cause it to be called instead of returning the property.
There are several problems with this approach:
1) Currently __get() is only checked/invoked if there is not a property already defined; ie properties shadow __get() (no performance penalty)
2) It would dramatically reduce performance because every property access would have to create the function string, get it's hash value and do a hash look up against the function table, just to see if there is a properly named accessor function. Failing that it would then check for the existence of a property and failing that move on to looking up __get
-Clint
On 10/27/2012 2:14 PM, Patrick Schaaf wrote:
On Saturday 27 October 2012 13:05:27 Clint Priest wrote:-- -ClintThat's why I think they shouldn't even be visible to users, they aren't relevant to them and in fact it could mis-lead them into thinking that they could simply define __getHours() and expect $foo->Hours to call it, which it wouldn't.I would expect / want it to do so. I see it this way: Defining semantics for magic methods named __prop_get_XXX, __prop_set_XXX etc as a specialization of __get/__set used whenever they exist for a given $XXX, is in my eyes a complete, proper accessor enhancement, saving me from doing a switch dance in __get/__set. The implementation should be absolutely straightforward, in the place where a missing property now tests for existence of __get/__set, a first, additional test for the specifically named __prop_get_XXX method would be added. Your proposed accessor _syntax_ is purely syntactic sugar, implementable on top of the functionality of the previous paragraph and implemented in terms of automatic code generation for it. This syntactic sugar could be separately implemented, discussed in a separate RFC,etc. The added complexity that I see, and I think Stas has meant to mention a lot of times, is everything - all code and documentation and explanation - that stems from NOT making it that two-step process. And in my opinion that would be completely superfluous, as it brings neither functionality nor syntax, just random additional issues. best regards Patrick