Why is everyone so dead set against read-only and write-only?
I could not disagree more with you on what is "pretty" and "readable".
To me:
public read-only $hours {
get { ... }
}
Is infinitely more readable and understandable than:
public $hours {
get() { ... }
private final set($value) { ... }
}
The latter implies that it can be "set" within the right context (internally to
the class), which is precisely the opposite of what is desired (read only).
From: Jazzer Dane [mailto:tbprogram...@gmail.com]
Sent: Wednesday, October 10, 2012 9:18 PM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
This all sounds about right.
In regards to #4 - read-only/write-only:
I think that, from a "pretty syntax" point of view, private final set() {} and
private final get() {} are definitely our best bets. But... from a logical
point of view, I prefer read-only/write-only.
private final get() {} is technically saying it will always return null.
private final set() {} is technically saying that setting doesn't do anything -
but it still works.
But I don't see any sane scenario where someone would want to do the above.
Therefore, it may just be best to use them in place of the currently proposed
read-only/write-only.
On Wed, Oct 10, 2012 at 5:35 PM, Clint Priest
<cpri...@zerocue.com<mailto:cpri...@zerocue.com>> wrote:
Okay, I would like this to be the last time there are revisions to this RFC.
To sum up the last few days of conversations, I have these down as points of
contention:
1. Accessor functions should not be present on the object and callable
directly, for example, $o->__getHours() should not be allowed.
2. Preferred syntax for accessors should be "public set($value) { ... }" with
no "magic" $value (with possible type hinting)
3. Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing most everyone.
4. read-only / write-only keywords, keep them or get rid of them? There is no
directly suitable replacement but I believe a private final set() { } will take
care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate for
accessors
6. The "truth" of reflection. Should it reveal details internal to how PHP
works on the inside or should it reflect the way PHP presents it as options?
Did I miss anything?
I will come up with some way for people to vote on the issues at hand and we
can cast our votes and be done with it, then I will finish the project and get
it out the door.
-Clint
