On 10/10/12 10:46 PM, Jazzer Dane wrote:
If at all possible, I'd rather not add extra keywords such as read-only and
write-only to the language. If it's unnecessary than it shouldn't be done -
that's my point of view. The question is thus "is read-only necessary?".
The proposal brought up by someone else was using
private final set($value) {}
and
private final get() {}
With no code in-between the braces, the functions are not accessible, not
extensible, and pointless. Thus we could arguably use them as alternatives
to the proposed read/write-only syntax.
But, in my previous emai,l I brought up the fact that this proposal isn't
that logically sound. The above lines of code don't exactly mean that
get/set aren't allowed... but at the same time, I don't know of any
scenarios where a developer would want to use private final get/set wherein
null is always returned or nothing is ever set.
The fact that this proposal is consistent with the language is a plus to
me. But I don't think it's enough - I don't like the logical
inconsistencies it brings.
If I were to vote between the two as to which gets implemented into PHP, I
would probably lean towards read/write-only, but I'm not a fan of either.
In the end, we need it to be logical. Good looking, consistent syntax is
nice, but having something behave even a little bit illogically is not at
all okay.
On Wed, Oct 10, 2012 at 7:59 PM, Clint Priest <cpri...@zerocue.com> wrote:
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>
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****
** **
I suspect this will be unpopular, but is there room in PHP to consider
that the developer will do "whatever they want" with any classes they
are using?
In an instance where the developer wants to change a property defined as
private, they generally have the option to change the class themselves,
and make it public.
Same with final - if they want to extend a class and overload "final"
functions, they can change the finality in the overloaded class. Of
course, this is true for private and protected as well.
There is a lot of discussion over read-only, but in the end it ends up
only as a "suggestion" to the developer using it. Why not just make
set() a no-op, if this is what you want to achieve, and document it as
such? I'm not sure why there is so much talk about this feature. It
doesn't really gain us anything, in my opinion (however, I feel that way
about "final," which is in the language already).
/**
* @read-only
*/
public $property {
get() { ... }
set;
}
If a developer wants to ignore the defined rules of a class, they can -
and if they do, bugs in their code are entirely on them.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
