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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
