Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64832
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50E79D16.1090905@zerocue.com>
References: <50E41BB6.4030901@zerocue.com>
	<50E648BE.2060005@zerocue.com>
	<50E6822D.9060807@sugarcrm.com>
	<71B3F435-4289-473B-B4D7-EB2DB5F888A9@zerocue.com>
	<7213E637-26A2-4F44-82DE-297E751726CD@zerocue.com>
	<50E6F501.4090806@zerocue.com>
	<50E75658.6050006@sugarcrm.com>
	<50E79D16.1090905@zerocue.com>
Date: Fri, 11 Jan 2013 00:15:33 +0100
Message-ID: <CAF+90c9HRNGQBP1j6pWcEoKJTF9hjpXTHQ2Egnj2WBBc37Uw2Q@mail.gmail.com>
To: Clint Priest <cpriest@zerocue.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8f234d2b0d72e604d2f75b34
Subject: Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
From: nikita.ppv@gmail.com (Nikita Popov)

--e89a8f234d2b0d72e604d2f75b34
Content-Type: text/plain; charset=ISO-8859-1

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

--e89a8f234d2b0d72e604d2f75b34--