RE: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces

> -----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. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227