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

I acquiesce to this issue, I agree that declaring a property in a class which implements an interface which has designated an accessor does indeed satisfy the accessor. But I think it would be very poor programming practice to do it. Anyone else have anything to say about this issue? > -----Original Message----- > From: David Muir [mailto:davidkmuir@gmail.com] > Sent: Tuesday, October 16, 2012 11:20 PM > To: Clint Priest > Cc: Stas Malyshev; Nikita Popov (nikita.ppv@gmail.com); internals@lists.php.net > Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces > > On 16/10/12 22:34, Clint Priest wrote: > > > >> -----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. > > > > 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