Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64837
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.183 as permitted sender)
Message-ID: <50EF56BD.3040608@sugarcrm.com>
Date: Thu, 10 Jan 2013 16:03:09 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Nikita Popov <nikita.ppv@gmail.com>
CC: Clint Priest <cpriest@zerocue.com>, 
 PHP Developers Mailing List <internals@lists.php.net>
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>
In-Reply-To: <CAF+90c9HRNGQBP1j6pWcEoKJTF9hjpXTHQ2Egnj2WBBc37Uw2Q@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> 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.

Object property fetches are not that hard, but parent::$foo is static
fetch - which is entirely different beast which uses different opcodes
and works differently. And is not supported by object handlers - mainly
because there's no object :) If we designed it from scratch, we could
probably make a class an object of type Class and probably avoided that
problem, since we could just use standard object handlers for that, but
it is not what currently happens. If somebody feels ambitious he may
explore that direction.

> 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

Well, it partially does, since ->foo part works exactly like in any
other expression. But parent-> part and the whole dollar-less variable
seems foreign for me too, so I am not happy with this one either.

> 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 makes tons of sense, but it means there's an object called
$parent. Now the question is where this one came from?

> 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:

This is an interesting approach. I like the idea of using the reflection
instead of inventing an awkward new syntax. However, I'm not sure I can
see how get_parent_property('foo') works - what exactly is 'foo' here?
Does it mean this function relies on implied $this? I'm not sure we
should be adding functions that do this. I'd rather have something like:
ReflectionProperty::getParentProperty($this, 'foo')

And yes, I know it's long-winded. But on the plus since it's generic,
does not pollute global space and might also be useful in other contexts.

Even more generic, we just could use existing ReflectionProperty like
this (this is standard API, no changes needed):

(new ReflectionProperty(get_parent_class(), 'foo'))->setValue($this, $val);

Yes, this is even more long-winded, that's why maybe we should have
shortcut function for it. Depends on how frequently in practice we
expect to do it.

> 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

I like this approach more too.

> 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,

I'm afraid we couldn't though since parent::$foo already means something
else - it's a static property "$foo" of the class that is parent of
current class. We could redefine it in this specific context, in theory,
but that would be strange special case and I don't think it would be
good idea to do that. Our syntax kind of assumes the object has only one
class and all properties belong to this class, so we don't have a proper
syntax to express the idea of "same property, but with different scope".

> 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

If you assume current property you'd have to store it somewhere to pass
it and have API for that function to extract it, which sounds like very
tight coupling for this function. Maybe something like __PROPERTY__
would be better?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227