Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63484
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
Message-ID: <507E3209.2050806@gmail.com>
Date: Wed, 17 Oct 2012 15:20:25 +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: Stas Malyshev <smalyshev@sugarcrm.com>, 
 "Nikita Popov (nikita.ppv@gmail.com)" <nikita.ppv@gmail.com>,
 "internals@lists.php.net" <internals@lists.php.net>
References: <9570D903A3BECE4092E924C2985CE485612B6466@MBX202.domain.local> <507D2AB5.1000903@sugarcrm.com> <9570D903A3BECE4092E924C2985CE485612B6C88@MBX202.domain.local> <507D3F8A.5040402@sugarcrm.com> <9570D903A3BECE4092E924C2985CE485612B6DF5@MBX202.domain.local>
In-Reply-To: <9570D903A3BECE4092E924C2985CE485612B6DF5@MBX202.domain.local>
Content-Type: text/plain; charset=ISO-8859-1; 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 22:34, Clint Priest wrote:
>
>> -----Original Message-----
>> From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
>> Sent: Tuesday, October 16, 2012 6:06 AM
>> To: Clint Priest
>> Cc: Nikita Popov (nikita.ppv@gmail.com); internals@lists.php.net
>> Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
>>
>> Hi!
>>
>>> that supports properties in interfaces.  Again, not exhaustive either
>>> but there is one language that does support accessors in interfaces
>>> and that's C#.
>> So what C# does when mixing regular properties and accessorized properties?
> I'd have to do some research to know for sure, but it's highly likely that they cannot be mixed.
>>> Think about it, if you allowed an outside caller of your class to
>>> modify your internal state, any time you needed to use that internal
>>> state you would have to validate it before you could rely upon its
>>> value to be set correctly.  No such issue exists with accessors in an
>> I do not see why this assumption is made that I need to do some special validation each time state is changed. In fact, in 99% of
>> existing code it is not happening, and I assume this ratio will be kept even when accessors are available. Most code will be very
>> straightforward, not doing anything complex with the state.
> If you have a public property $a which internally can only deal with it being set to 2 or 3 and someone external to the class sets it to 4, your class either has to check that it's 2 or 3 and deal with the fact that it is now 4 or have indeterminate results when it is set to 4.
>
>> Now, I think the bigger question is: what exactly you want to say/require when you write:
>>
>> interface a { public $xyz { get; } }
>>
>> and what is the use case for this requirement?
> The use case is that you are declaring that interface a must allow a property $xyz to be readable and *not* writable.
>
>>> Just to be a bit more concrete here, as the code is presently written
>>> and because I have strongly separated the concept of a property vs an
>>> accessor, this code:
>>>
>>> interface a { public $xyz { get; } }
>>>
>>> class b implements a { public $xyz; }
>>>
>>> Produces the following error: Fatal error: Class b contains 3 abstract
>>> accessors and must be declared abstract or implement the remaining
>>> accessors (get a::$xyz, isset a::$xyz, ...) in %s on line %d
>> I think this is wrong. 3 abstract accessors is especially wrong since it doesn't match the direct interface definition and is very
>> confusing (see my earlier point about isset/unset always having fallback defaults) but even with get as abstract I do not see a valid
>> use case that would require such behavior. What you want is for any $foo that is instanceof a to be able to respond to read request
>> to $foo->xyz, right? Class b satisfies this requirement, why you reject it then?
>> Also, if you reject it - how I should fix it to make it work? Would I have to implement a bolierplate getter/setter just to make
>> interface work? Doesn't look like a good proposition to me.
> Class b does not satisfy the requirement because you are missing the fact that public $xyz { get; } forbids setting of $xyz, only reading it.
>

That doesn't make sense. An implementation has to have the same or less 
restricted visibility, so the above should work. The inverse however 
should not:

interface a { public $xyz; }

class b implements a { public $xyz { get; }}


Daivd