> -----Original Message----- > From: ekne...@gmail.com [mailto:ekne...@gmail.com] On Behalf Of Etienne Kneuss > Sent: Monday, October 15, 2012 9:10 AM > To: Clint Priest > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces > > Hi, > > On Mon, Oct 15, 2012 at 3:55 PM, Clint Priest <cpri...@zerocue.com> wrote: > > I would bet, that at present, what you've put down is not allowed because I > > purposely leveraged functions in this regard because > all of the restrictions put in place against functions would apply to > accessors (because they are functions). I would have to test it to > be certain though. > > > > Because of Nikita's desire to not have underlying __getXX() functions > > exposed in any way this may have to change. I had spent > several hours actually divorcing the created function from the Functions > HashTable and later realized I could simply enforce their > non-existence at call time, this has turned somewhat problematic for static > accessors though. > > > > Also, your "should be valid" statement implies that you feel properties and > > accessors are the same and they are not, internally. > When a class attempts to implement an interface a "function check" is done > and since there is no __getXX() function defined it > would fail to implementation check against an interface. > > > > I cannot stress enough that properties != accessors in any way except the > > syntax in which they are used ($o->xyz) or ($o->xyz = 1), > that is their *only* similarity. > > I not saying accessors are properties. I'm saying that interfaces define > usage contracts. And from the point of view of usage contacts: > > interface A { > public $a {get; set; } > } > > is entirely fulfilled by the class: > > class B extends A { > public $a; > } > > You can see a public property as an underlying private property with all > usual public accessors defined. > > From the point of view of the user both should be interchangeable > transparently. >
I *think* we are on the same page here, though I'm not sure what 'user' is referring to (user of interface "implementer") or (user of class B). In any case, I don't believe that your class B would be allowed at present, but if it is, then it should not be allowed because defining a property to satisfy the requirements of an accessor is not right.
