RE: [PHP-DEV] (*PATCH*) getters/setters Implementation

From: Date: Sat, 31 Mar 2012 13:19:35 +0000
Subject: RE: [PHP-DEV] (*PATCH*) getters/setters Implementation
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
The patches are applied to this fork if anyone wants to check it out:

https://github.com/cpriest/php-src


-----Original Message-----
From: Clint M Priest [mailto:[email protected]] 
Sent: Thursday, March 29, 2012 8:14 PM
To: [email protected]
Subject: RE: [PHP-DEV] (*PATCH*) getters/setters Implementation

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. 

For the auto-backed properties it would be assigned to whatever value was being passed, null or
whatever.  For the non auto-backed properties it would depend on the user-supplied getter/setter
implementation.  Am I missing something 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 with 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 there are none,
anyone else see any backward compatibility issues?

-----Original Message-----
From: Christopher Jones [mailto:[email protected]] 
Sent: Thursday, March 29, 2012 1:14 PM
To: [email protected]
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? 
> Attached is a patch against ~/trunk

A couple of brief comments from the sidelines without having followed previous discussion in detail:

- The RFC appears to have open questions e.g about the need for readonly etc 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 merged/completed.
- If these are indeed magic methods they need "__" prefixes, so consider the 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: [email protected]
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


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Thread (5 messages)

« previous php.internals (#59268) next »