Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61313
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 74.125.82.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPaKmR=rveMOaGXWjx=9s2-fU86BRe90yScwbd60hJN+-g6c3w@mail.gmail.com>
References: <CAPaKmRmn+L081722PHdzJFEO4wRyGTixacLZ38FTyBr-s8Up3w@mail.gmail.com>
 <CAF+90c-yQe4Hjh=1KUAhN0XFkSp1OXevcvuHXiBJ2Y0isU=QeQ@mail.gmail.com> <CAPaKmR=rveMOaGXWjx=9s2-fU86BRe90yScwbd60hJN+-g6c3w@mail.gmail.com>
Date: Mon, 16 Jul 2012 16:26:36 +0100
Message-ID: <CAN+gjSfEt=24WvRxzEVu250U-Qm3kv1-j=qeQ7+819+oBP62gA@mail.gmail.com>
To: Amaury Bouchard <amaury@amaury.net>
Cc: Nikita Popov <nikita.ppv@gmail.com>, internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] RFC Proposal - Attributes read/write visibility
From: ajfweb@googlemail.com (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 <amaury@amaury.net> wrote:
> 2012/7/16 Nikita Popov <nikita.ppv@gmail.com>
>
>> 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/