There's no way to stop the developer from doing that without read-only.
Yes, there is - I don't even know why would write it that way - doesn't
seem to make much sense.
What you probably should be doing, is this:
class A {
private $seconds = 3600;
public $hours {
get() { return $this->seconds / 3600 };
}
}
Keep your field private - now try extending this with a write-accessor.
I think that read-only is really almost merely a "pseudonym" for "read-only
accessor for a private field" - what you're really trying to do, is protect
the field behind the accessor, not the accessor itself.
In the same way, write-only is practically synonymous with "write-only
accessor for a private field" - to some extend (at least) the point of
having accessors to begin with, is to protect the underlying value(s) from
unauthorized or incorrect use.
You can relax your read-only or write-only accessors by declaring the
backing field(s) protected - this would be the equivalent of declaring a
read-only accessor that you are permitted to extend with a write-accessor
if you need to...
---------- Forwarded message ----------
From: Jazzer Dane tbprogrammer@gmail.com
To: Leigh leight@gmail.com
Cc: Clint Priest cpriest@zerocue.com, "internals@lists.php.net" <
internals@lists.php.net>
Date: Tue, 9 Oct 2012 19:33:20 -0700
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
class A {
public $seconds = 3600;
public $hours {
get() { return $this->seconds / 3600 };
}
}class B extends A {
public $hours { // Maintains 'get' from class A
set($value) { $this->seconds = $value; }
}
}^There's no way to stop the developer from doing that without read-only.
Jazzer's example was extending an accessor and her statement about no way to stop the developer from doing what she did there without read-only is correct.
There are other, more verbose and less simple ways to accomplish read-only and write-only (preventing sub-classes from defining a getter, etc, namely through the use of final) but none of them are as simple and easily readable as public read-only $hours { ... }
-----Original Message-----
From: Rasmus Schultz [mailto:rasmus@mindplay.dk]
Sent: Wednesday, October 10, 2012 6:47 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1There's no way to stop the developer from doing that without read-only.
Yes, there is - I don't even know why would write it that way - doesn't seem to make much sense.
What you probably should be doing, is this:
class A {
private $seconds = 3600;public $hours {
get() { return $this->seconds / 3600 };
}
}Keep your field private - now try extending this with a write-accessor.
I think that read-only is really almost merely a "pseudonym" for "read-only accessor for a private field" - what you're really trying to
do, is protect the field behind the accessor, not the accessor itself.In the same way, write-only is practically synonymous with "write-only accessor for a private field" - to some extend (at least) the
point of having accessors to begin with, is to protect the underlying value(s) from unauthorized or incorrect use.You can relax your read-only or write-only accessors by declaring the backing field(s) protected - this would be the equivalent of
declaring a read-only accessor that you are permitted to extend with a write-accessor if you need to...---------- Forwarded message ----------
From: Jazzer Dane tbprogrammer@gmail.com
To: Leigh leight@gmail.com
Cc: Clint Priest cpriest@zerocue.com, "internals@lists.php.net" < internals@lists.php.net>
Date: Tue, 9 Oct 2012 19:33:20 -0700
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1class A {
public $seconds = 3600;
public $hours {
get() { return $this->seconds / 3600 };
}
}class B extends A {
public $hours { // Maintains 'get' from class A
set($value) { $this->seconds = $value; }
}
}^There's no way to stop the developer from doing that without read-only.
Just a couple of quick remarks.
Clint wrote:
I'm not even sure that automatic backing fields are even desired, I never
felt the need to have them in C# and the only reason they were included is
because they were a part of Dennis's original proposal.
Automatic backing fields are indeed necessary in C# for various technical
reasons none of which have any bearing on the PHP language - Nikita
explained this in another e-mail. So I vote for dropping automatic
auto-implemented accessors. In PHP, an auto-implemented accessor really
would be almost identical to a regular property anyhow.
I would also add that the double-underscore convention for the field-name
seems somewhat spooky to me - double-underscore is generally reserved for
PHP internal stuff... now suddenly these would be userland-fields. Seems
wrong.
Clint, I am sorry these issue were not surfaced earlier... I do seem to
recall sending a very long e-mail highlighting many of these issues a long
while back though (?) ... I only watch the list with half an eye, but I
usually speak up when I feel strongly about something. You're doing a great
job here! I hope you you will see it through - this would be a fantastic
feature which will make for better code architecture in so many ways.