Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64539 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 97487 invoked from network); 5 Jan 2013 03:31:45 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Jan 2013 03:31:45 -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:47319] helo=mail.zerocue.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 59/49-38386-0AE97E05 for ; Fri, 04 Jan 2013 22:31:44 -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 73E3E12034E; Sat, 5 Jan 2013 03:31:40 +0000 (UTC) Message-ID: <50E79E98.8090209@zerocue.com> Date: Fri, 04 Jan 2013 21:31:36 -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: Stas Malyshev CC: Nikita Popov , PHP internals References: <50E6F2EB.20108@zerocue.com> <50E757E1.8060803@sugarcrm.com> In-Reply-To: <50E757E1.8060803@sugarcrm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors From: cpriest@zerocue.com (Clint Priest) On 1/4/2013 4:29 PM, Stas Malyshev wrote: > Hi! > >> This shouldn't be an issue because it is not possible to set the >> property without going through the setter, which would be a type hinted >> accessor function. > It is possible, if this property's guard is set. Since guard works for > all code called from inside the setter, if setter is doing something not > trivial (meaning, calls any functions, explicitly or implicitly) it is > possible to set the property directly. Since the value you are getting > is defined by the getter, there are no guarantees there too. So > effectively, unless both getter and setter are implicit, this does not > give you anything compared to the typed setter. I think I was referring to the possibility I mentioned in another email about a second call to a getter which was already guarded would return NULL and likewise a second call to a setter which was already being guarded would do whatever __set() does...? Ignored? -- -Clint