I haven't done an exhaustive analysis of every language out there that supports
interfaces but to my knowledge there isn't a single one that supports
properties in interfaces. Again, not exhaustive either but there is one
language that does support accessors in interfaces and that's C#.
When I refer to "communicate" for an interface I am referring to the fact that
if a property were allowed and a consumer of an object which implements that
property changes that property, the object will not know about it until it has
its own code run through some other method, whereas with an accessor the object
will "hear about it" right away.
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 interface as the communication about its
change attempt is resolved immediately (and can be rejected or accepted).
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
This fatal error actually occurs during the *function check* phase of interface
checking, because public $xyz {get;} represents a set of functions that must be
defined (accessors).
> -----Original Message-----
> From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
> Sent: Tuesday, October 16, 2012 4:37 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!
>
> > I think that accessors should be allowed with interfaces because an
> > interface really is a specification on how to communicate and while
> > accessors do pass messages, properties do not.
>
> "Communicate" is a loaded term. Property access is communication too, but
> properties aren't defined in the interfaces. In any case,
> if you're allowing accessors in interface, you should bring back automatic
> implementation of accessors, since if you're saying "you
> must provide property $a" I should be able to say "OK, here's property $a,
> working exactly as plain old PHP property". Either that or
> I'd have to write a boilerplate code (and make a couple of errors on the way
> such as breaking references and isset, which 99% of
> less-experienced PHP programmers would do).
> I think accessors in interfaces are a huge can of worms because of their
> potential of mixing function calls and property access, while
> the latter is traditionally not the domain of the interface. We should
> carefully consider if we really have use case for it. Especially
> given that PHP always has underlying default property access functionality
> that is always available - unlike methods which if not
> defined lead to fatal error. So while if you do $foo->bar() on wrong $foo it
> will break, if you do $foo->bar on wrong $foo yu just get
> default behavior. Given that, do we really need an interface there?
> --
> 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
