On 16/10/12 22:34, Clint Priest wrote:
-----Original Message----- From: Stas Malyshev [mailto:[email protected]] Sent: Tuesday, October 16, 2012 6:06 AM To: Clint Priest Cc: Nikita Popov ([email protected]); [email protected] 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 anI 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 %dI 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.
That doesn't make sense. An implementation has to have the same or less restricted visibility, so the above should work. The inverse however should not:
interface a { public $xyz; }
class b implements a { public $xyz { get; }}
Daivd
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
