Re: Re: internals Digest 4 Feb 2012 09:08:29 -0000 Issue 2549

From: Date: Sat, 04 Feb 2012 18:20:51 +0000
Subject: Re: Re: internals Digest 4 Feb 2012 09:08:29 -0000 Issue 2549
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-57711@lists.php.net to get a copy of this message
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


« previous php.internals (#57711) next »