Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64513 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 53144 invoked from network); 4 Jan 2013 03:13:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Jan 2013 03:13:14 -0000 Authentication-Results: pb1.pair.com header.from=cpriest@zerocue.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=cpriest@zerocue.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 67.200.53.250 as permitted sender) X-PHP-List-Original-Sender: cpriest@zerocue.com X-Host-Fingerprint: 67.200.53.250 mail.zerocue.com Received: from [67.200.53.250] ([67.200.53.250:59100] helo=mail.zerocue.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 68/A9-00128-8C846E05 for ; Thu, 03 Jan 2013 22:13:14 -0500 Received: from [172.17.0.122] (unknown [66.25.151.173]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.zerocue.com (Postfix) with ESMTPSA id 5455B120340 for ; Fri, 4 Jan 2013 03:13:10 +0000 (UTC) Message-ID: <50E648BE.2060005@zerocue.com> Date: Thu, 03 Jan 2013 21:13:02 -0600 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: PHP Developers Mailing List References: <50E41BB6.4030901@zerocue.com> In-Reply-To: <50E41BB6.4030901@zerocue.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue From: cpriest@zerocue.com (Clint Priest) Note, there has been a show stopper of an issue with the current RFC that many minds have been talking about how to solve. The problem is with parent::$foo accessing the parent accessor. In summary, the difficulty is that this is parsed as a static property access and during compilation there is no guarantee that the parent class structure can be accessed (to confirm/deny that it's really an accessor and not a static property reference). This guarantee is not possible because you can define the parent class after the subclass. So... on to solutions that have been discussed and shot down. 1) Change the zend opcodes for static property references to identify the true state at run-time. This would be a "hack" to be certain and has been shot-down for that exact reason. This is also the reason that static accessors has been abandoned for this first iteration of the feature, because static properties are handled entirely differently from object based properties. 2) Rewrite the way static property references work, such that they make calls into zend_object_handler.c, which is probably something that should be done anyways as a separate RFC and project, at which point this problem would probably be trivial to solve. 3) Introduce a new opcode which could somehow solve this problem by introducing an additional step to determine whether its a parent accessor reference or a static property reference. This would also be "hackish" because the proper solution is #2 and beyond the scope of this RFC. A recent suggestion from Stas is to use parent->$foo (note the use of -> rather than ::) Pros: - It should not have any problems being implemented - It would move this RFC to completion Cons: - It does create an inconsistency in that nowhere else (that I know of) does parent->$foo do something. It may also sound like it should work because parent::__construct() works just fine, but that works fine because it goes through a different opcode system than static accessors do. Really, other than doing something like the above, the only other way would be for a getter to access it's parent by calling the function directly, such as parent::__getFoo() but this is undesirable for a number of reasons: 1) It forces the user to access the parent property accessor in a different way than is used everywhere else 2) It forces the user to utilize an underlying implementation detail that is not guaranteed to stay the same (it may change) 3) It's certainly not as syntactically nice as parent->$foo would be. As a final alternative to this problem, we could simply not allow a parents accessor to be used, which I think is probably the worst choice of all. Thoughts? There is a github ticket discussing this issue as well here if you'd like to chime in there on some more technical conversation about this issue: https://github.com/cpriest/php-src/issues/8 If anyone can think of any other way to solve this such that parent::$foo could work, I'm all ears but I'm out of ideas on this one and I think Stas's idea is just fine. On 1/2/2013 5:36 AM, Clint Priest wrote: > Here is the updated RFC incorporating the feedback from previous > rounds of discussion. > > https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 > > I'm posting it for final review so I can move to voting on Jan 7th. > > Please note that the current fork is not quite up-to-date with the RFC > but will be within a few more days. > > -Clint > -- -Clint