Re: Property Accessors v1.2 : Interfaces

From: Date: Tue, 16 Oct 2012 11:05:46 +0000
Subject: Re: Property Accessors v1.2 : Interfaces
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-63456@lists.php.net to get a copy of this message
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? > 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. 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? > 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. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227

« previous php.internals (#63456) next »