RE: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces

> -----Original Message----- > From: ekneuss@gmail.com [mailto:ekneuss@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 <cpriest@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.