Re: Property Accessors 1.2 : parent::$foo Issue
| From: | Steve Clay | Date: | Fri, 11 Jan 2013 01:38:20 +0000 |
| Subject: | Re: Property Accessors 1.2 : parent::$foo Issue | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-64841@lists.php.net to get a copy of this message | ||
Why we must have parent property access at all? What's the use case and how do other langs do
it?
Am I right to say there is no "parent property", this would just call the parent's
[gs]etter using the same underlying property value?
Steve
--
http://www.mrclay.org/
On Jan 10, 2013, at 6:15 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Sat, Jan 5, 2013 at 4:25 AM, Clint Priest <cpriest@zerocue.com> wrote:
>
>> Agreed. Some people may actually be using $parent as a variable name, not
>> difficult to imagine.
>>
>> So far parent->foo seems to be the answer.
>>
>> -Clint
>
> My thoughts on the parent situations, as I'm not yet satisfied with the
> current solution.
>
> 1) I tried to understand how the engine currently compiles and executes
> object property fetches. I found it to be incredibly complex and I
> certainly don't have the abilities to port this for statics. As such the
> "parent::$foo" syntax is dead unless someone else is going to do the
> necessary engine changes.
>
> 2) I think the "parent->foo" syntax is nice in concept, but I think that
> it's an absolute no-go as it doesn't fit in with the rest of PHP (and would
> still require some engine changes those complexity I can't really
> estimate). The parent->foo syntax is some off mix between parent::$foo
> (which makes sense) and $parent->foo (which also makes sense). parent->foo
> combines it in an odd way that doesn't look like PHP and adds yet another
> new syntax for something that's going to be a rare case anyway.
>
> 3) My suggestion is to avoid the engine and syntax related issues of parent
> property access by putting this as a function in the standard library
> instead. What I'm thinking about is a function like get_parent_property()
> which returns the ReflectionProperty for it. Then you could do something
> like this:
>
> public $foo {
> get { return 'parent is: ' .
> get_parent_property('foo')->getValue(); }
> set($val) { get_parent_property('foo')->setValue($val . '
> something'); }
> }
>
> I know that this is not an optimal solution, but I would much prefer this
> over some new syntax like "parent->foo". Once (if) static properties have
> better engine support we can switch to the cleaner parent::$foo way. But
> until then I think that this is a good compromise, especially considering
> that accessing the parent property shouldn't be a very common operation, so
> it's okay if it's a bit more verbose.
>
> This is just a rough idea of what I'd do. The exact way this would work
> still needs further discussion. E.g. one could make passing the property
> name optional and assume the current property as default. Or one could not
> return a ReflectionProperty and instead provide two functions
> get_parent_property and set_parent_property (what about isset and unset in
> that case though?)
>
> So, what do you think about this?
>
> Nikita