Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63551
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: <CAPaKmRmghPKO-4wTFXVTpiUeb8mY34B799PgTLmiTtx3fw-ZkQ@mail.gmail.com>
References: <9570D903A3BECE4092E924C2985CE485612C2595@MBX214.domain.local>
	<CAPaKmRmghPKO-4wTFXVTpiUeb8mY34B799PgTLmiTtx3fw-ZkQ@mail.gmail.com>
Date: Sat, 20 Oct 2012 11:05:00 +0200
Message-ID: <CAF+90c8T3yVja_kL=zrh=QSZW9jyQw1Kq9LLMi+sNqdH4sOrgQ@mail.gmail.com>
To: Amaury Bouchard <amaury@amaury.net>
Cc: 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 9:29 AM, Amaury Bouchard <amaury@amaury.net> wrote:
>   read-only => final set null;
> It begins to be verbose.
>
> As I said many times, why don't you want to use the "const" keyword? It
> already exists and is pretty well understood by everybody.
Could you maybe explain where exactly "const" would be used? Please
don't forget that we do not use your "foo:bar" syntax, so where would
the "const" go with the currently used syntax?

Anyway, I'd like to give a quick comment on read-only: I mainly don't
like the keyword because it doesn't do what I expect it to do. When I
first glanced over the RFC I thought that read-only was a way to
define read-only properties (i.e. properties that can only be set via
default value or in the constructor) along the lines of "public
read-only $name = 'FooBar';". This is what the "readonly" modifier
means in C# (which is the language the RFC is adopted from mainly). In
C# readonly can *not* be added to properties with accessors, only to
simple fields. With the current RFC / the original proposal
"read-only" gets a completely different meaning.

I think that the behavior of the modifier in C# is useful, whereas its
behavior in the original accessors proposal is mostly pointless. I
mean, why would you need to strictly enforce that a property is
read-only throughout the inheritance hierarchy? From an interfacing
(LSP) point of view it's not of importance whether an additional set
accessor is added, as long as the get accessor stays. I would guess
that "read-only" will be used about as much as "final" is used today.
And "final" is nearly never used.

That's why I really don't think that we need any kind of special
syntax for this. If you do happen to be the rare case where you need
to enforce the read-only-ness throughout the hierarchy, you can always
use the "final private set()" approach (maybe even throwing an
exception from it so you can't even access it from within the class).
Everything else seems unnecessary to me and would only make things
more complicated than necessary.

Nikita