I guess my thought behind it was that __set() is supposed to be called whenever writing data to inaccessible properties, I sought not to change the default behavior of __set(). In the case of adding a read-only keyword was that it was explicitly stating that the property cannot be written to in any way.
-----Original Message----- From: Sebastian Krebs [mailto:krebs....@googlemail.com] Sent: Saturday, February 04, 2012 12:21 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] Re: internals Digest 4 Feb 2012 09:08:29 -0000 Issue 2549 Hi, Am 04.02.2012 19:13, schrieb Clint M Priest: > > > -----Original Message----- > From: Rasmus Schultz [mailto:ras...@mindplay.dk] > Sent: Saturday, February 04, 2012 10:01 AM > To: internals@lists.php.net > Subject: [PHP-DEV] Re: internals Digest 4 Feb 2012 09:08:29 -0000 > Issue 2549 > >> Why can't the read-only and write-only keywords be implicit instead of >> explicit? I've never seen another language where you have to explicitly >> indicate what you're doing. At> best, it acts an extra fail-safe to prevent >> making errors - at worst, it just means more redundant code to maintain, >> more ways to make errors. Do the benefits really outweigh> the value of >> this? > > The read-only and write-only keywords act a little differently. Without > them, attempting a set on an accessor without a setter defined will cause > __set() to be called whereas with the read-only it will produce an error. > The inverse is true for write-only. I attempted to keep the ability to have > lazy initializing of properties via accessors, but that could be written in > php slightly differently if the read-only/write-only keywords were not > present (due to guards). Doesn't particularly matter to me. Just curious: Why? Whats the benefit in allowing "get" directly and "set" via __set() at the same time? > >> Regarding automatic implementations - according to the wiki, the >> backing field is implemented as public. Is that correct? Most other >> languages don't even expose the existence of the backing field. Would it not >> be more correct to implement an auto-backing field as protected? The reason >> for implementing accessors in the first place, is usually to prevent direct >> access to an underlying field. > > Makes sense, in C# these backing fields are completely inaccessible directly, > would that be even better in this case or would protected suffice? > >> Since a high degree of explicitness seems to be a design goal, it >> would probably make more sense if you had to use reflection to access a >> backing-field without invoking the accessor-methods. > >> Looks nice otherwise! :-) > >> - Rasmus > > 2012/2/4<internals-digest-h...@lists.php.net> > >> From: Clint M Priest<cpri...@zerocue.com> >> To: "internals@lists.php.net"<internals@lists.php.net> >> Cc: >> Date: Fri, 3 Feb 2012 13:47:53 +0000 >> Subject: [PATCH] Property Getters/Setters (v2.4) for review The >> property accessor functionality is done and is detailed here: >> https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented >> >> Core Patch: >> http://www.clintpriest.com/patches/php-core/accessors/2.4.diff >> >> The core patch encompasses the entire original RFC and the >> as-implemented includes implementation details and edge cases not >> defined by the original RFC. >> >> Most changes are in zend_compile, zend_object_handlers and >> zend_language_scanner. >> >> Thanks, >> >> -Clint > -- 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
