Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61319
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
Sender: amaury.bouchard@gmail.com
In-Reply-To: <CAF+90c8TiLDMGAFHopx4hQfOgE1S4r9V0VCrRQ46HM=o5DnT8w@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> <CAF+90c8TiLDMGAFHopx4hQfOgE1S4r9V0VCrRQ46HM=o5DnT8w@mail.gmail.com>
Date: Mon, 16 Jul 2012 17:41:50 +0200
Message-ID: <CAPaKmRmtTwTFETW=Urdr3ooB0jmWshY1PdzVodOsZhCiREaJ_w@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=e89a8f642feef47b2704c4f445b0
Subject: Re: [PHP-DEV] RFC Proposal - Attributes read/write visibility
From: amaury@amaury.net (Amaury Bouchard)

--e89a8f642feef47b2704c4f445b0
Content-Type: text/plain; charset=ISO-8859-1

Are you sure that this mix of distributed visibilities (sometimes before
the attribute, sometimes before a "get" or "set" keyword) and new keywords
("read-only" and "write-only", between the initial visibility and the
attribute itself; but what is an "initial visibility" exactly?) is really
more clear?

Take this code, for instance:
    public read-only $a {
        protected get;
        private set;
    }

Yeah, I know, the "public" should be "protected". But in some years, when
you'll have some legacy code, I'm pretty sure we will see this kind of
code. It should work, the "public" visibility is just overloaded by the
"protected" and "private" visibilities. Anyway, it's perturbing.
Oh, and there is a "read-only" keyword. Damned, I added a private setter, I
forgot it was read-only and I forgot to remove it...

So, I guess it should be like that:
    protected $a {
        private set;
    }

Then, try to read this code aloud. I'm really not sure it's better than a
simple "protected:private $a;", which could be read like "protected
reading, private writing".


2012/7/16 Nikita Popov <nikita.ppv@gmail.com>

> On Mon, Jul 16, 2012 at 5:24 PM, Amaury Bouchard <amaury@amaury.net>
> wrote:
> > 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.
>
> You can also just write public $a { get; private set; }. I see that
> the syntax is a bit more verbose, but I definitely prefer it to the
> obscure public:private notation. With the getters/setters the meaning
> is somewhat clear (public get, private set), with the colon notation
> it isn't really clear.
>
> Nikita
>

--e89a8f642feef47b2704c4f445b0--