Re: Property Accessors v1.2 : Interfaces

On 16/10/12 13:37, Clint Priest wrote:

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. I'm not sure I understand what you're getting at here Etienne, this thread was about interfaces but now you're talking about two classes...

From an interface standpoint, both classes implement the same property. One as a literal property, the other as an accessor. The point being, from the code consuming the class, a property and accessor are the same thing. Interfaces are about contracts between an implementation and a consumer, so the actual implementation is irrelevant. What matters is how the implementation is accessed by the consumer. If it is via property syntax, then it *is* a property, even though the actual implementation might be a property, an accessor or (in theory) even __get/__set. Cheers, David