Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63559
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
In-Reply-To: <CAF+90c_-wrQPqR-_Cuiqfc7jGyXM=OmfyfK21iovQVaPQBGrEg@mail.gmail.com>
References: <9570D903A3BECE4092E924C2985CE485612C2595@MBX214.domain.local>
 <CAPaKmRmghPKO-4wTFXVTpiUeb8mY34B799PgTLmiTtx3fw-ZkQ@mail.gmail.com>
 <CAF+90c8T3yVja_kL=zrh=QSZW9jyQw1Kq9LLMi+sNqdH4sOrgQ@mail.gmail.com>
 <CACxA8b=fa615T--ON4tswTYsE1gy95G1an7=YGQ2ur5at9nLcA@mail.gmail.com> <CAF+90c_-wrQPqR-_Cuiqfc7jGyXM=OmfyfK21iovQVaPQBGrEg@mail.gmail.com>
Date: Sat, 20 Oct 2012 03:15:12 -0700
Message-ID: <CACxA8bnaJapcB-5YP04ms5+aDHYSvEDn90enXvWiXN-dBPsbng@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Amaury Bouchard <amaury@amaury.net>, Clint Priest <cpriest@zerocue.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04446a498bdf1f04cc7ae6da
Subject: Re: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords
From: tbprogrammer@gmail.com (Jazzer Dane)

--f46d04446a498bdf1f04cc7ae6da
Content-Type: text/plain; charset=ISO-8859-1

Nikita, there appears to be a slight misunderstanding. You're initial email
was worded in a way that I presumed you were attacking the final keyword
entirely, not just final methods. You are correct in that many PHP
frameworks don't have final *functions*.

My pushing for the read-only functionality is that it, in my opinion,
necessary for cohesiveness with the final keyword.

The read-only implementation we are still working on creating is
essentially a magic version of

> final set() { throw new ReadonlyPropertyException; }
>

In regards to your third point: Clint sent an email a few days wherein he
implied you were the driving factor behind automatic accessors. Sorry for
the confusion.

Asymmetric accessor visibility is a different subject. It's moderately
convenient but I'm worried there's too much magic going on in the
background and it's not apparent what the syntax means. We should probably
open up another discussion thread for this subject, though.

On Sat, Oct 20, 2012 at 2:52 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Sat, Oct 20, 2012 at 11:31 AM, Jazzer Dane <tbprogrammer@gmail.com>
> wrote:
> > The final keyword is used, especially in sizable OOP applications.
> Claiming
> > it supposedly isn't used very often anymore - even if it were true - is
> not
> > an excuse to exclude the "read-only"-esque functionality in this RFC.
> Firstly, I didn't make that claim out of thin air, I actually checked
> how many final methods are used in ZF and Symfony (which are my usual
> reference projects due to their large size) and from that concluded
> that "nearly never" is a very accurate description. It could obviously
> be that those two projects are somehow special and everyone else uses
> large amounts of final methods ;)
>
> Secondly, low anticipated use is actually a very good reason to
> exclude functionality. One shouldn't add features from which you know
> right from the start that nearly no-one will use them.
>
> Thirdly, I don't want to exclude the possibility of enforcing
> read-only-ness through the hierarchy. I just don't want to provide a
> dedicated syntax for such an edge case. As already mentioned, there
> already are sufficiently simple ways to do this:
>
>     // read-only for all classes in the hierarchy, only the current one
> can read
>     final private set();
>     // absolutely read-only
>     final private set() { throw new ReadonlyPropertyException; }
>
> The latter is even rather clear about the intention ;)
>
> > My top choice is final get;, which would work quite well and
> non-ambiguously
> > if we don't implement Nikita's proposed automatic accessor functions or
> > implement it in a noticeably different syntax.
> Not sure where you got that, but automatic accessor implementations
> are not my idea, they were part of the original proposal. I wanted to
> remove them, but later we found that they are necessary for various
> aspects of the RFC, in particular asymmetric accessor visibility
> (public $foo { get; protected set; }). Unless you want to drop that
> too automatic implementations have to stay.
>
> Nikita
>

--f46d04446a498bdf1f04cc7ae6da--