RE: [PHP-DEV] [RFC] Propety Accessors v1.1

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<mailto: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