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
