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
>
