> -----Original Message-----
> From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
> Sent: Tuesday, October 16, 2012 6:06 AM
> To: Clint Priest
> Cc: Nikita Popov (nikita....@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
