Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63506
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 74.115.204.41 as permitted sender)
To: David Muir <davidkmuir@gmail.com>, Stas Malyshev <smalyshev@sugarcrm.com>,
	"Nikita Popov (nikita.ppv@gmail.com)" <nikita.ppv@gmail.com>
CC: "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/AgADkZYD//7ifQA==
Date: Wed, 17 Oct 2012 12:37:02 +0000
Message-ID: <9570D903A3BECE4092E924C2985CE485612B7D3C@MBX202.domain.local>
References: <9570D903A3BECE4092E924C2985CE485612B6466@MBX202.domain.local>
 <507D2AB5.1000903@sugarcrm.com>
 <9570D903A3BECE4092E924C2985CE485612B6C88@MBX202.domain.local>
 <507D3F8A.5040402@sugarcrm.com>
 <9570D903A3BECE4092E924C2985CE485612B6DF5@MBX202.domain.local>
 <507E3209.2050806@gmail.com>
In-Reply-To: <507E3209.2050806@gmail.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 acquiesce to this issue, I agree that declaring a property in a class whi=
ch implements an interface which has designated an accessor does indeed sat=
isfy the accessor. =20

But I think it would be very poor programming practice to do it.

Anyone else have anything to say about this issue?

> -----Original Message-----
> From: David Muir [mailto:davidkmuir@gmail.com]
> Sent: Tuesday, October 16, 2012 11:20 PM
> To: Clint Priest
> Cc: Stas Malyshev; Nikita Popov (nikita.ppv@gmail.com); internals@lists.p=
hp.net
> Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interface=
s
>=20
> On 16/10/12 22:34, Clint Priest wrote:
> >
> >> -----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 :
> >> 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 proper=
ties?
> > I'd have to do some research to know for sure, but it's highly likely t=
hat 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 kep=
t 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/requ=
ire 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 pr=
operty $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 t=
o $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 w=
ork? Doesn't look like a good proposition to me.
> > Class b does not satisfy the requirement because you are missing the fa=
ct that public $xyz { get; } forbids setting of $xyz, only
> reading it.
> >
>=20
> That doesn't make sense. An implementation has to have the same or less r=
estricted visibility, so the above should work. The
> inverse however should not:
>=20
> interface a { public $xyz; }
>=20
> class b implements a { public $xyz { get; }}
>=20
>=20
> Daivd