Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63459
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 74.115.204.53 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+D//+E4AIAAPK/A
Date: Tue, 16 Oct 2012 11:34:01 +0000
Message-ID: <9570D903A3BECE4092E924C2985CE485612B6DF5@MBX202.domain.local>
References: <9570D903A3BECE4092E924C2985CE485612B6466@MBX202.domain.local>
 <507D2AB5.1000903@sugarcrm.com>
 <9570D903A3BECE4092E924C2985CE485612B6C88@MBX202.domain.local>
 <507D3F8A.5040402@sugarcrm.com>
In-Reply-To: <507D3F8A.5040402@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)



> -----Original Message-----
> From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
> Sent: Tuesday, October 16, 2012 6:06 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
> > that supports properties in interfaces.  Again, not exhaustive either
> > but there is one language that does support accessors in interfaces
> > and that's C#.
>=20
> So what C# does when mixing regular properties and accessorized propertie=
s?

I'd have to do some research to know for sure, but it's highly likely that =
they cannot be mixed.
>=20
> > 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
>=20
> I do not see why this assumption is made that I need to do some special v=
alidation each time state is changed. In fact, in 99% of
> existing code it is not happening, and I assume this ratio will be kept e=
ven 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 bei=
ng 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:
>=20
> interface a { public $xyz { get; } }
>=20
> and what is the use case for this requirement?

The use case is that you are declaring that interface a must allow a proper=
ty $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
>=20
> 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 i=
t then?
> Also, if you reject it - how I should fix it to make it work? Would I hav=
e 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 t=
hat public $xyz { get; } forbids setting of $xyz, only reading it.

> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227