Re: [RFC] Propety Accessors v1.1

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 <cpriest@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:tbprogrammer@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 <cpriest@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.