You really don't want to even think about my idea? It's complementary on some aspects, you know.
2012/10/11 Clint Priest <cpri...@zerocue.com> > 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:cpri...@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 >