Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63308
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.220.170 cause and error)
MIME-Version: 1.0
Date: Tue, 9 Oct 2012 19:46:41 -0400
Message-ID: <CADqTB_hvmWp5D7JeLTnW2MFOt5XhDi+V3-hmeVwiw1D2S-Lh9Q@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf3071cf982b529804cba8f399
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
From: rasmus@mindplay.dk (Rasmus Schultz)

--20cf3071cf982b529804cba8f399
Content-Type: text/plain; charset=ISO-8859-1

This looks great, and essentially has everything I had hoped for!

My only remaining comment is on the read-only and write-only keywords...
this seems really superfluous and strange to me - the syntax (using a
hyphenated keyword) and the feature itself, is way off the grid as compared
to other languages.

In my opinion, this is a feature that is so exotic, it's likely to never
actually be used by anyone.

What I dislike the most about this feature, is that it's existence may
mandate a "best practice" of declaring read-only properties as read-only.
What I mean is, because this feature exists, anytime you're declaring
something that is read-only by nature (because a write-accessor makes no
logical sense), you would be expected to declare such a property as
read-only.

In other words, not using the read-only keyword for a property that only
has a read-accessor, can only be interpreted in two ways:

1. it's an oversight, or simply bad practice.

2. it's an implied invitation to implement the write-accessor in an
extension.

Case 1 of course shouldn't happen, while case 2 would be an extremely
exotic and far-fetched scenario.

I understand the justification for this keyword - but the use-cases are
just too rare, and they don't, in my opinion, outweigh the disadvantages.

This feature just feel clumsy and out of place to me. I will never use it,
and I would strongly prefer not to have to think about it, having to
declare read-only and write-only deliberately. For 95% of cases, it's going
to be perfectly obvious, both to me and other consumers of the code, why or
whether something is read-only or write-only, and the extra guarantee or
insulation against error in the marginal 5% of cases do not justify the
effort of having to declare it explicitly everywhere.

Just my two cents...


----

Subject: [PHP-DEV] [RFC] Propety Accessors v1.1

It's been a while since I posted any updates about this, a few individuals
have been asking about it privately and wanting me to get it out the door
for PHP 5.5 release.  It's come a long way since the last time I posted
about it.

RFC Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented

--20cf3071cf982b529804cba8f399--