Rather than go to the trouble of finding a reasonable way to hold a vote on
these issues, is there anyone against the following changes:
1) Eliminate the ability for an accessor to be called via $o->__getHours(), the
accessor functions will be completely unavailable for use except as property
references ($o->Hours)
2) Change syntax to use public set($value) { }, public get(), etc. (and along
with that means no more "magic" $value)
2a) If possible, allow for Type Hinting...
3) Eliminate automatically implemented get; set;, no automatic backing field
creation will occur.
4) read-only / write-only keywords will be eliminated
5) Exceptions thrown from accessors will be made more appropriate (I will also
check debug_backtrace information, etc)...
If there isn't anyone against the above changes, I will make the changes to the
RFC and re-present for final agreement...
Or... do ya'll want to vote on the aforementioned changes?
> -----Original Message-----
> From: Clint Priest [mailto:[email protected]]
> Sent: Wednesday, October 10, 2012 7:36 PM
> To: [email protected]
> Subject: RE: [PHP-DEV] [RFC] Propety Accessors v1.1
>
> 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
