RE: [PHP-DEV] Re: internals Digest 4 Feb 2012 09:08:29 -0000 Issue 2549

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.seb@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:rasmus@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-help@lists.php.net> > >> From: Clint M Priest<cpriest@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