A couple of quick comments...
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
-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 - Issue 2549
Why can't the read-only and write-only keywords be implicit instead
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 - Issue 2549
Why can't the read
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 - Issue 2549
Hi,
Am 04.02.2012 19:13, schrieb Clint M Priest
On Sat, Feb 4, 2012 at 1:13 PM, Clint M Priest cpri...@zerocue.com wrote:
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.
Yes, *something* has to be able to access the backing field to
implement such things, but as long as the class itself and its
subclasses can do so (protected) it seems like a feature not to have
the property outright public so the getters and setters don't get
ignored by the people who should be
