My choice of words were misleading/incorrect. If you are programming to an
interface then the interface dictates what *will* work, if you attempt to use
an interface to do something that the interface has not declared is supported
then it may work or it may fail.
On Oct 16, 2012, at 7:43 AM, "Stas Malyshev" <smalys...@sugarcrm.com> wrote:
> Hi!
>
>> 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.
>
> Most of the properties, however, aren't of that nature.
>
>> The use case is that you are declaring that interface a must allow a
>> property $xyz to be readable and *not* writable.
>
> Why would you require for the implementor to *not* be able to do
> something? Interfaces were never used to make class *not* be able to do
> something. Are you sure it's good thing to introduce this? I think it's
> not. I think interfaces should only define "X should work" but not "Y
> should not work".
>
>> Class b does not satisfy the requirement because you are missing the
>> fact that public $xyz { get; } forbids setting of $xyz, only reading
>> it.
>
> See above, I think it's not the right use of interfaces. Also, error
> message produced has nothing in common with this logic.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
