Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64841
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mrclay.org from 50.22.11.19 cause and error)
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> <CAF+90c9HRNGQBP1j6pWcEoKJTF9hjpXTHQ2Egnj2WBBc37Uw2Q@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAF+90c9HRNGQBP1j6pWcEoKJTF9hjpXTHQ2Egnj2WBBc37Uw2Q@mail.gmail.com>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-ID: <AC711083-EFF3-4F72-93C5-F196E0910C97@mrclay.org>
Cc: Clint Priest <cpriest@zerocue.com>,
 Stas Malyshev <smalyshev@sugarcrm.com>,
 PHP Developers Mailing List <internals@lists.php.net>
Date: Thu, 10 Jan 2013 20:38:20 -0500
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
From: steve@mrclay.org (Steve Clay)

Why we must have parent property access at all? What's the use case and how d=
o other langs do it?

Am I right to say there is no "parent property", this would just call the pa=
rent's [gs]etter using the same underlying property value?

Steve
--=20
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:
>=20
>> Agreed.  Some people may actually be using $parent as a variable name, no=
t
>> difficult to imagine.
>>=20
>> So far parent->foo seems to be the answer.
>>=20
>> -Clint
>=20
> My thoughts on the parent situations, as I'm not yet satisfied with the
> current solution.
>=20
> 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.
>=20
> 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 woul=
d
> 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.
>=20
> 3) My suggestion is to avoid the engine and syntax related issues of paren=
t
> 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:
>=20
>     public $foo {
>         get { return 'parent is: ' .
> get_parent_property('foo')->getValue(); }
>         set($val) { get_parent_property('foo')->setValue($val . '
> something'); }
>     }
>=20
> 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, s=
o
> it's okay if it's a bit more verbose.
>=20
> 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?)
>=20
> So, what do you think about this?
>=20
> Nikita