Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63557
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CACxA8b=fa615T--ON4tswTYsE1gy95G1an7=YGQ2ur5at9nLcA@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>
Date: Sat, 20 Oct 2012 11:52:24 +0200
Message-ID: <CAF+90c_-wrQPqR-_Cuiqfc7jGyXM=OmfyfK21iovQVaPQBGrEg@mail.gmail.com>
To: Jazzer Dane <tbprogrammer@gmail.com>
Cc: Amaury Bouchard <amaury@amaury.net>, Clint Priest <cpriest@zerocue.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords
From: nikita.ppv@gmail.com (Nikita Popov)

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