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**** > > ** ** >