Re: [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
| From: | Stas Malyshev | Date: | Mon, 29 Oct 2012 21:56:06 +0000 |
| Subject: | Re: [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-63707@lists.php.net to get a copy of this message | ||
Hi!
> If I got it right now, what Stas wants is that we introduce __getFoo
> and __setFoo methods that will be called whenever an undefined ->foo
> property is accessed and that the "normal" property accessors syntax
> is made nothing more than a fancy notation for this.
Yes, pretty much, though "undefined" bit is not required I think. Not
100% convinced on this, but from user reqs it sounds like they want to
drop the undefined bit.
> A) Inheritance:
> ==========
>
> class A {
> public $foo;
> }
>
> class B extends A {
> public $foo { get() { ... } set($value) { ... } }
> }
>
> => With the accessors syntax there is an expectation that the accessor
> declaration will override the previous plain property. At least that's
> what I would expect and that's what the code looks like
That's why I'm not liking the "undefined" bit.
> => With the magic syntax there is the expectation that the $foo
> property will not be overridden. Rather the magic functions are
> expected to do nothing, because the property already exists.
Err, I'm not sure why that would be the expectation. __get is for
undefined properties, since, well, it doesn't have any property name
attached, so it can't really be for defined properties :) However,
__getFoo (with whatever variations the bikeshedding committee will end
up with :) has property name attached to it, so requiring property be
undefined is not, well, required. Here we need to think which way is
better, and I currently tend to think accessor priority is better.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227