Re: Property Accessors v1.2 : Interfaces

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