Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64840 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 61153 invoked from network); 11 Jan 2013 00:57:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Jan 2013 00:57:22 -0000 Authentication-Results: pb1.pair.com smtp.mail=nikita.ppv@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=nikita.ppv@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.181 as permitted sender) X-PHP-List-Original-Sender: nikita.ppv@gmail.com X-Host-Fingerprint: 209.85.217.181 mail-lb0-f181.google.com Received: from [209.85.217.181] ([209.85.217.181:45158] helo=mail-lb0-f181.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 33/73-02684-0736FE05 for ; Thu, 10 Jan 2013 19:57:21 -0500 Received: by mail-lb0-f181.google.com with SMTP id ge1so923962lbb.40 for ; Thu, 10 Jan 2013 16:57:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W04O2vpuq8kWuw/ZeJ5d929L+1aFi+b3B8k7SJTQgiA=; b=T2EqaaW99mq5JL4BB7H3H1lKHpxzIqbDpi38hfsGEkbhLGaL2wRv0IUzYSgnkfQLKa 6+xDgBmed9+iH9WJ2UK1uM2V0tx6i7T8z40lfo0fln0SElU+T33x6iXxLoFeOUgYJ2gG tXhUHvyLcRxkgSN021kbs7bif6H6IqI19hilkIalYr0uDqNv9uGLfWZGwTdo6+JT6aXt DyXPO11BCZ/BfmmY34ICenGKJ0bNADTepR28g0TYYqG7+UF/i0rIuUqwZcI5nVGq0ncd ghsyuuCs+8FNQc57emygt6iq7UE4sWx6SYqz9qUm/dZ6BP4cqhRFanIamh71Cl3KuCFS osUg== MIME-Version: 1.0 Received: by 10.112.46.37 with SMTP id s5mr30174513lbm.67.1357865837543; Thu, 10 Jan 2013 16:57:17 -0800 (PST) Received: by 10.112.4.168 with HTTP; Thu, 10 Jan 2013 16:57:17 -0800 (PST) In-Reply-To: <50EF56BD.3040608@sugarcrm.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> <50EF56BD.3040608@sugarcrm.com> Date: Fri, 11 Jan 2013 01:57:17 +0100 Message-ID: To: Stas Malyshev Cc: Clint Priest , PHP Developers Mailing List Content-Type: multipart/alternative; boundary=bcaec554e156e641bd04d2f8c621 Subject: Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue From: nikita.ppv@gmail.com (Nikita Popov) --bcaec554e156e641bd04d2f8c621 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 11, 2013 at 1:03 AM, Stas Malyshev wrote: > > 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 wrote that without actually checking the Reflection API, I forget that one has to pass the object too. So my code samples should rather look like this: get_parent_property('foo')->getValue($this); get_parent_property('foo')->setValue($this, ...); 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. > Re the ReflectionProperty::getParentProperty($this, 'foo') suggestion, is this supposed to already get the value of the property (and there would be an additional method ReflectionProperty::setParentProperty)? 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". > 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. > > 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 --bcaec554e156e641bd04d2f8c621--