Re: Property Accessors 1.2 for Final Review before Vote
| From: | Clint Priest | Date: | Thu, 03 Jan 2013 10:40:06 +0000 |
| Subject: | Re: Property Accessors 1.2 for Final Review before Vote | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-64494@lists.php.net to get a copy of this message | ||
That has not been covered and it is a problem, just tested it.
Anyone have any preferences on a resolution?
Only thing that really needs to occur is that the function names need to be unique, we could prefix any capitals in a variable name with an additional _ such that:
class A {
public $Foo { get; set; }
public $foo { get; set; }
}
Would mean there would be these function names:
A::__get_Foo();
A::__set_Foo();
A::__getfoo();
A::__setfoo();
Along w/ their unset/isset'rs.
This is what happens as of right now:
Fatal error: Cannot redeclare a::__getfoo() in /opt/php-core/git/trunk-accessor/cpriest/php/quick2.php on line 9
Good catch on that one.
On 1/2/2013 11:52 PM, Steve Clay wrote:
On Jan 2, 2013, at 10:24 PM, Clint Priest <cpriest@zerocue.com> wrote:-- -ClintI've updated the Shadowing section of the RFC which I hope clears this up, it also includes a slightly modified version of your example at the bottom with comments.Updated RFC really helps. The notion of $this->prop access semantics depending on which accessor you're in seems important for the RFC as I think it will seem foreign to a lot of devs. When I make traditional PHP "accessor" methods, I have complete control; if I want getFoo() to set private $foo without calling setFoo(), I can. Not so with real accessors. Probably a good thing :) One more concern, sorry if it was covered already: will case-insensitivity of methods mean you can't define getters for both $foo and $Foo? Steve