Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64556 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 80896 invoked from network); 5 Jan 2013 19:05:41 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Jan 2013 19:05:41 -0000 Authentication-Results: pb1.pair.com smtp.mail=cpriest@zerocue.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=cpriest@zerocue.com; 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:58122] helo=mail.zerocue.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 63/23-62408-48978E05 for ; Sat, 05 Jan 2013 14:05:41 -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 B2AA3121072; Sat, 5 Jan 2013 19:05:37 +0000 (UTC) Message-ID: <50E8797C.7030203@zerocue.com> Date: Sat, 05 Jan 2013 13:05:32 -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: Steve Clay CC: Stas Malyshev , "internals@lists.php.net" References: <50E41BB6.4030901@zerocue.com> <50E4A43E.6030302@zerocue.com> <50E4B232.5000505@mrclay.org> <50E4BDDE.8050509@zerocue.com> <50E4D0BB.7060701@mrclay.org> <50E4FA09.7030001@zerocue.com> <50E529B6.1050903@sugarcrm.com> <50E593DF.9090004@mrclay.org> <50E60994.4000400@sugarcrm.com> <50E86BBB.2080104@mrclay.org> In-Reply-To: <50E86BBB.2080104@mrclay.org> Content-Type: multipart/alternative; boundary="------------020808080902080303070705" Subject: Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote From: cpriest@zerocue.com (Clint Priest) --------------020808080902080303070705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I like the alternate idea here, but I'm not sure what advantage it has over the current situation? ------------------------------------------------------------------------ This line of reasoning revealed a difference between what your verbiage suggestion from a few days ago suggests and what is true. With the "guards" it's pretty simple what occurs. If an unset (accessor) is called, and another unset is called on that property, the same internal function which handles unset is called. In the 2nd instance, it see's that the unset is already being guarded and so the ordinary "unset" functionality is invoked. Therefore, take a look at this gist: https://gist.github.com/4463107 I will need to update the RFC because your previous summary which I took verbatim I missed being incorrect. It's really, in my book, a lot simpler to say that if an accessor is already "in the call chain" then it will not be called again and "standard property rules" take effect. This is why a getter can get its value directly. It's also why if that getter calls some other code which tries to "get" the value, that get also bypasses the getter (which prevents infinite loops). -Clint On 1/5/2013 12:06 PM, Steve Clay wrote: > On 1/3/13 5:43 PM, Stas Malyshev wrote: >> The whole problem here is that the only reason why it is a problem is >> because of the accessors that have hidden state in guards. If it were >> regular variables (and for all the API consumer knows, they are) there > > Please ignore this if it's been debated before: > > AFAICT C# strictly separates fields ("properties" in PHP) and > properties (a set of accessors that emulate a field). > > So the RFC provides 3 features (using C# terms): > 1. A property API > 2. A built-in storage variable so you don't need a separate field > 3. Access to the storage variable as if it were a field of the same name > > I think #2 is useful, avoiding the need to make a separate field just > to make properties read-only or type-hinted. However I think the > complexity and confusion we're running into is mostly caused by #3. > > I think we might be better served by having another way to access this > storage variable. > > What if instead, we have the storage var available as $prop inside all > the accessors? These would be the default implementations: > > get { return $prop; } > set($value) { $prop = $value; } > isset { return $prop !== NULL; } > unset { $prop = NULL; } > > Pros: > * Makes clear that $prop is regular var access, and that > $this->PropertyName *always* goes through accessors > * Gives isset/unset full access to the storage var, which allows doing > things that can't be done via setter/getter. E.g. you could actually > implement a property being "unset", which would be different from > having it set to NULL. > > Cons: > * Allows "evil", like having reads affect the storage var. > * Allows authors to hang themselves with recursive accessor calls, BUT > those mistakes would be apparent from looking at the code. > > What functionality possible in the RFC would be lost by this? > > Steve Clay -- -Clint --------------020808080902080303070705--