Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:61589 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 37707 invoked from network); 20 Jul 2012 22:48:03 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Jul 2012 22:48:03 -0000 X-Host-Fingerprint: 208.107.183.205 host-205-183-107-208.midco.net Date: Fri, 20 Jul 2012 18:48:03 -0400 Received: from [208.107.183.205] ([208.107.183.205:23635] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2F/31-18983-220E9005 for ; Fri, 20 Jul 2012 18:48:03 -0400 Message-ID: <2F.31.18983.220E9005@pb1.pair.com> To: internals@lists.php.net References: User-Agent: slrn/pre1.0.0-18 (Linux) X-Posted-By: 208.107.183.205 Subject: Re: [PHP-DEV] RFC Proposal - Attributes read/write visibility From: weierophinney@php.net (Matthew Weier O'Phinney) On 2012-07-16, Amaury Bouchard wrote: > --f46d0446312cc5e06104c4f42161 > Content-Type: text/plain; charset=ISO-8859-1 > > My point is not to add two ways to do the same thing. > What I'm humbly suggesting to do is to keep the core idea of the > existing RFC (make things easier when you have to write > getters/setters), and think about another syntax for managing reading > and writing visibilities. My first impression, being familiar with the other proposal, was that this looked like duplication. However, on looking at the examples, I have to admit that I really like the approach -- in many cases, it obviates the need for a getter entirely. It would help dry up a lot of code, reduce the number of method calls overall, and still enforce internal logic when setting the value in the first place. I like it; it feels elegant. > 2012/7/16 Andrew Faulds > >> How much syntactic sugar do we really need? Why add two ways to do >> something? >> >> On 16 July 2012 16:24, Amaury Bouchard wrote: >> > 2012/7/16 Nikita Popov >> > >> >> I'm not sure I really understand what this adds over the existing >> >> getter/setter proposal. read-only and write-only should cover the most >> >> common cases. If you do need visibility control, it is possible too: >> >> >> >> public $property { >> >> get { ... } >> >> protected set { ... } >> >> } >> >> >> >> So what does this proposal add to it? >> >> >> >> >> > Yes, but only if you have to write an accessor. >> > If you just want an attribute that is: >> > - readable from everywhere >> > - writable from the current class only >> > >> > With my syntax: >> > public:private $a; (read it aloud "public reading, private writing") >> > >> > With the existing RFC: >> > public $a { >> > private set { $this->a = $value; } >> > } >> > >> > Which one is better? Why should I write code for that? >> > >> > If you read the existing RFC, you'll see that all examples involve a >> > specific case: when you have a "fake" attribute, which manipulates date >> > stored in other attributes. The given example is an $Hours attributes, >> > which is calculated from the private $Seconds attribute. >> > Again, it could be very useful. But it doesn't work all the time. >> >> >> >> -- >> Andrew Faulds (AJF) >> http://ajf.me/ >> > > --f46d0446312cc5e06104c4f42161-- -- Matthew Weier O'Phinney Project Lead | matthew@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc