Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63428
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.42 as permitted sender)
Message-ID: <507CD7ED.3000301@gmail.com>
Date: Tue, 16 Oct 2012 14:43:41 +1100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Clint Priest <cpriest@zerocue.com>
CC: Etienne Kneuss <colder@php.net>, 
 Levi Morrison <morrison.levi@gmail.com>,
 "internals@lists.php.net" <internals@lists.php.net>
References: <9570D903A3BECE4092E924C2985CE485612B6466@MBX202.domain.local> <CACQesk5MLCqhdKr9j30WmL6ySTeMpVVEs9q2UfOjYbA+4bp_Yw@mail.gmail.com> <9570D903A3BECE4092E924C2985CE485612B655A@MBX202.domain.local> <CACQesk4q-YLPkn=ECHsNcTmoanzKVH8eN8iZ-LW-wULn7_rbHQ@mail.gmail.com> <9570D903A3BECE4092E924C2985CE485612B6654@MBX202.domain.local> <CAFMT4NqymNn3sH_HEH9GieHAys2i+NDSm=78NeuN-TdqVSig=A@mail.gmail.com> <56FF073D-826C-444F-8843-9739E568919E@zerocue.com> <CACQesk7ui8Xjk6xdhzZk9xJoayK291OHXYxbEiYbBBQGOqfC3w@mail.gmail.com> <9570D903A3BECE4092E924C2985CE485612B69D2@MBX202.domain.local>
In-Reply-To: <9570D903A3BECE4092E924C2985CE485612B69D2@MBX202.domain.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
From: davidkmuir@gmail.com (David Muir)

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