Re: Property Accessors v1.2 : Interfaces

Hi, On Mon, Oct 15, 2012 at 6:02 PM, Clint Priest <cpriest@zerocue.com> wrote: > Because fundamentally interfaces are designed to explain a way of communicating and properties > are symmetrical and non-observable. > > The implementing class cannot "know" when a property has changed. Do you agree that there is nothing that distinguishes class A { public $v; } from class B { private $_v; public $v { get { return $this->v; }; set($n) { $this->v = $n; }} } when it comes to a client of B reading and writing to $b->v ? That's the entire point of accessors: being able to seamlessly intercept usages of properties with custom code. If you define an interface saying interface A { public $v { get;set;} } you are only saying to the user: objects of type A will have a property $v that you can read and write to. Whether it is a set of accessors or a property belongs to the implementation detail of the class implementing A, the user should not be able to see a difference when interacting with the class, as he will do it through $obj->v and $obj->v = ...; I can understand why we might not want that in PHP in order to simplify the implementation, but it we follow logical reasoning I can't see why we shouldn't implement that. This discussion makes we wonder about another aspect of the patch that is unclear: class A { public $v = 2; } class B extends A { public $v { get { .. }; set { .. } }; } Will $b->v trigger the accessors, will it ignore them and access "v" in the properties table, or is overriding existing properties using accessors rejected during compilation? Best, > > -Clint > > On Oct 15, 2012, at 9:37 AM, "Levi Morrison" <morrison.levi@gmail.com> wrote: > >>> 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. >> >> According to whom? In my opinion, not allowing a property to satisfy >> the requirement of an accessor is wrong. -- Etienne Kneuss http://www.colder.ch