Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63448
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 74.115.204.51 as permitted sender)
To: Stas Malyshev <smalyshev@sugarcrm.com>
CC: "Nikita Popov (nikita.ppv@gmail.com)" <nikita.ppv@gmail.com>,
	"internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
Thread-Index: Ac2qzmY/IrEbFiHmS8CRVRSeKx1+9gA1OcmAAAbzj+A=
Date: Tue, 16 Oct 2012 10:32:02 +0000
Message-ID: <9570D903A3BECE4092E924C2985CE485612B6C88@MBX202.domain.local>
References: <9570D903A3BECE4092E924C2985CE485612B6466@MBX202.domain.local>
 <507D2AB5.1000903@sugarcrm.com>
In-Reply-To: <507D2AB5.1000903@sugarcrm.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: RE: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
From: cpriest@zerocue.com (Clint Priest)

I haven't done an exhaustive analysis of every language out there that supp=
orts interfaces but to my knowledge there isn't a single one that supports =
properties in interfaces.  Again, not exhaustive either but there is one la=
nguage that does support accessors in interfaces and that's C#.

When I refer to "communicate" for an interface I am referring to the fact t=
hat 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 unt=
il it has its own code run through some other method, whereas with an acces=
sor the object will "hear about it" right away. =20

Think about it, if you allowed an outside caller of your class to modify yo=
ur 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 correct=
ly.  No such issue exists with accessors in an interface as the communicati=
on 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 b=
ecause 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 abs=
tract 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 inter=
face checking, because public $xyz {get;} represents a set of functions tha=
t must be defined (accessors).

> -----Original Message-----
> From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
> Sent: Tuesday, October 16, 2012 4:37 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 : Interface=
s
>=20
> Hi!
>=20
> > 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.
>=20
> "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 automati=
c 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 ca=
refully consider if we really have use case for it. Especially
> given that PHP always has underlying default property access functionalit=
y 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