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 >