Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59214
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 74.115.204.40 as permitted sender)
To: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] (*PATCH*) getters/setters Implementation
Thread-Index: Ac0NWORG1bLWHQK7SWW3B6CwIICvWAAoEhWAAAYetnA=
Date: Fri, 30 Mar 2012 01:13:42 +0000
Message-ID: <9570D903A3BECE4092E924C2985CE4855467F6CC@MBX202.domain.local>
References: <9570D903A3BECE4092E924C2985CE485517221FD@MBX201.domain.local>
 <4F74A64B.50200@oracle.com>
In-Reply-To: <4F74A64B.50200@oracle.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: RE: [PHP-DEV] (*PATCH*) getters/setters Implementation
From: cpriest@zerocue.com (Clint M Priest)

Thanks for the feedback, I'll take care of some of these.

What did you mean about the out of sync regarding naming?

With the unexpected values to the methods I'm not sure what you mean, there=
 are no 'expected values' to be passed.=20

For the auto-backed properties it would be assigned to whatever value was b=
eing passed, null or whatever.  For the non auto-backed properties it would=
 depend on the user-supplied getter/setter implementation.  Am I missing so=
mething here?

Regarding the open questions on read-only/write-only I don't think they are=
 strictly necessary any longer.  The original RFC had them for enforcing a =
value to be read only but it would be equivalent of setting an accessor wit=
h just a getter and final although it would allow for it to be over-ridden.=
  Are the read-only/write-only tags desired?

I think the test cases that are present are complete, I could not think of =
any further tests to write or I would have written them, any suggestions?

I'll update the RFC with backward compatibility comments though I believe t=
here are none, anyone else see any backward compatibility issues?

-----Original Message-----
From: Christopher Jones [mailto:christopher.jones@oracle.com]=20
Sent: Thursday, March 29, 2012 1:14 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] (*PATCH*) getters/setters Implementation



On 03/28/2012 08:13 PM, Clint M Priest wrote:

> What are the next steps to get this added to some future release?=20
> Attached is a patch against ~/trunk

A couple of brief comments from the sidelines without having followed previ=
ous discussion in detail:

- The RFC appears to have open questions e.g about the need for readonly et=
c keywords
- The tests and RFC are out of sync regarding naming, e.g. readonly vs read=
-only
- The RFC makes no mention of backward compatibility issues
- Did I miss seeing tests that pass in unexpected values to the methods?
- I would expect a larger number of tests overall when the feature is merge=
d/completed.
- If these are indeed magic methods they need "__" prefixes, so consider th=
e names
   __getter and __setter
- I'd suggest biting the github bullet and creating your own PHP fork with =
your
   patches.  People will be able to test and you might get more feedback.

--
Email: christopher.jones@oracle.com
Tel:  +1 650 506 8630
Blog:  http://blogs.oracle.com/opal/

--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:=
 http://www.php.net/unsub.php