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

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:cpriest@zerocue.com] > Sent: Wednesday, October 10, 2012 7:36 PM > To: internals@lists.php.net > 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