Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64844
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 67.200.53.250 as permitted sender)
Message-ID: <50EF8EFC.7000108@zerocue.com>
Date: Thu, 10 Jan 2013 22:03:08 -0600
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Nikita Popov <nikita.ppv@gmail.com>
CC: Stas Malyshev <smalyshev@sugarcrm.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> <50EF56BD.3040608@sugarcrm.com> <CAF+90c9qFNHk7nev-OsnkCjRKCyvm=XgczY9ViS0tknZ9Q6qYA@mail.gmail.com>
In-Reply-To: <CAF+90c9qFNHk7nev-OsnkCjRKCyvm=XgczY9ViS0tknZ9Q6qYA@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------070005000507010002000309"
Subject: Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
From: cpriest@zerocue.com (Clint Priest)

--------------070005000507010002000309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


On 1/10/2013 6:57 PM, Nikita Popov wrote:
> 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 like this idea as a solution to the problem.  It would be ideal if 
parent::$foo would work but since that is not currently a reasonable 
option, either leaving the user land programmer to use reflection to do 
it or to provide them with a shortcut way to do it is a good interim 
solution to the problem.

I'm not sure that we really even need a 'shortcut' to do it, we'd need 
some other people to chime in on that and how often the parent accessor 
would want to be called.

>     > 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.
>
+1 as well
>
>
>     > 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".
>
>
> I try to see :: as a scope resolution operator rather than a static 
> access operator. For methods that's how it works (you can call 
> instance methods with it in a different scope, e.g. parent scope). So 
> doing the same for properties isn't far off. But yes, I do agree that 
> this would be rather tricky and could open another big can of worms 
> (like we have with method calls from incompatible contexts), so it 
> might not actually make sense to go down that path.
I agree with that general sentiment as :: as a scope resolution 
operator, it's just that right now, for ::$ that always translates to 
static property access which is the current conundrum.

>     > 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?
>
>
> The current property can be obtained through 
> EG(current_execute_data)->function_state.function. This holds the 
> accessor function and the property can be taken from its name. Though 
> this is obviously all a bit dirty and is probably not a good idea. 
> Probably better to let people explicitly pass the property name.
>
> Nikita

Is everyone okay with a long winded way to get/set the parent accessor 
if necessary?

(new ReflectionProperty(get_parent_class(), 'foo'))->setValue($this, $val);

Alternatively, reflection in some cases takes an object instance 
(ReflectionObject), we could extend ReflectionPropertyAccessor so that 
it could take an object, then something that is slightly shortened would 
work, like this:

(new ReflectionPropertyAccessor($this, 'foo'))->setValue(45);

That presently doesn't work, but could be made to work, especially 
considering it's a new sub-class anyways.

If we don't like setValue() being different b/w ReflectionProperty and 
ReflectionPropertyAccessor we could upgrade both classes to accept an 
object instance as its constructor argument...

-- 
-Clint

--------------070005000507010002000309--