Re: Property Accessors v1.2 : Interfaces

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" <smalyshev@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