Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63353
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain bouza.ch designates 62.146.34.176 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
In-Reply-To: <9570D903A3BECE4092E924C2985CE485612B526F@MBX202.domain.local>
Date: Thu, 11 Oct 2012 23:11:37 +0200
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <DACDB49F-348A-4993-91D6-97F834BFBA40@bouza.ch>
References: <9570D903A3BECE4092E924C2985CE485612B3B48@MBX202.domain.local> <5073328D.5000002@gmail.com>	<50735165.8010703@aaronholmes.net> <CAEPJdu=pRSDRD68t3o7XVbWRo-FvA07Wr+bzM_bwOXkwfiMxng@mail.gmail.com> <CACxA8bkF0EHDs3As=kMcg-BahRfBK6A5i7B9TdRc_SweCsv23A@mail.gmail.com> <9570D903A3BECE4092E924C2985CE485612B4353@MBX202.domain.local> <CACxA8b=wbHN_mRomH25Jr+i9BeTzj=VTGfPe_T8igjzCsMNn_Q@mail.gmail.com> <760ab4f994a78a846cf86aafda71e0e2@mohiva.com> <CALtuQzAH-=ePssPi-yUcXghpUhO6jOH4oDhDtPEFVj9bRf1VLA@mail.gmail.com> <9570D903A3BECE4092E924C2985CE485612B4EFE@MBX202.domain.local> <9570D903A3BECE4092E924C2985CE485612B526F@MBX202.domain.local>
To: Clint Priest <cpriest@zerocue.com>
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
From: manuel@bouza.ch (Manuel Bouza)

I'm in favor of all your points Clint and type hinting would be very =
valuable to me. Also, I would favor if reflection does not reveal =
internals either. If I am correct, that would require ReflectionClass to =
have getPropertyAccessors()/getPropertyAccessor('Hours') method and a =
new ReflectionPropertyAccessor class for property accessors.

My main point is regarding the read-only issue. I think that, given that =
the problem only arises when inheriting from a class defining a  =
property accessor, a solution would be not to allow to extend accessor =
property functions (get(), set(), isset() and unset()) that are not =
defined in the parent class. Otherwise, an error should be raised. =
Something similar is already implemented in PHP when overriding a parent =
method with a different signature. Here, we would not allow to implement =
a different "signature" for property accessors in the child class. So:

class Timing=20
{
	/* =85 */
=09
	/* set() not defined, setting $Hours is not allowed, $Hours is =
thus read-only, everybody should agree with this */
	public $Hours {
		get() { return $this->seconds / 3600; }
		final isset() { return isset($this->seconds); }
		unset() { unset($this->seconds); }
	}
}

class SpecialTiming extends Timing
{
	/** =85 */
	public $Hours {
		get() { return $this->seconds / 3600; } // <-- OK,=20
		set(TypeHint $value) { $this->seconds =3D 3600 * $value; =
} // <-- ERROR, set() not defined in parent class
		final isset() { return isset($this->seconds); } // <-- =
ERROR, isset() is final in parent class.
		/* unset inherited from parent class */
	}

}


Am 11.10.2012 um 21:45 schrieb Clint Priest <cpriest@zerocue.com>:

> Rather than go to the trouble of finding a reasonable way to hold a =
vote on these issues, is there anyone against the following changes:
>=20
> 1) Eliminate the ability for an accessor to be called via =
$o->__getHours(), the accessor functions will be completely unavailable =
for use except as property references ($o->Hours)
> 2) Change syntax to use public set($value) { }, public get(), etc.  =
(and along with that means no more "magic" $value)
> 2a) If possible, allow for Type Hinting...
> 3) Eliminate automatically implemented get; set;, no automatic backing =
field creation will occur.
> 4) read-only / write-only keywords will be eliminated
> 5) Exceptions thrown from accessors will be made more appropriate (I =
will also check debug_backtrace information, etc)...
>=20
> If there isn't anyone against the above changes, I will make the =
changes to the RFC and re-present for final agreement...
>=20
> Or... do ya'll want to vote on the aforementioned changes?
>=20
>> -----Original Message-----
>> From: Clint Priest [mailto:cpriest@zerocue.com]
>> Sent: Wednesday, October 10, 2012 7:36 PM
>> To: internals@lists.php.net
>> Subject: RE: [PHP-DEV] [RFC] Propety Accessors v1.1
>>=20
>> Okay, I would like this to be the last time there are revisions to =
this RFC.
>>=20
>> To sum up the last few days of conversations, I have these down as =
points of contention:
>>=20
>> 1.  Accessor functions should not be present on the object and =
callable directly, for example, $o->__getHours() should not be
>> allowed.
>> 2.  Preferred syntax for accessors should be "public set($value) { =
... }" with no "magic" $value (with possible type hinting) 3.
>> Automatically implemented get; set; with auto-backing field should be =
eliminated as this is not necessary for PHP and is confusing
>> most everyone.
>> 4.  read-only / write-only keywords, keep them or get rid of them?  =
There is no directly suitable replacement but I believe a private
>> final set() { } will take care of it, even though it much more =
verbose.
>> 5.  Error handling for thrown exceptions should be made more =
appropriate for accessors 6.  The "truth" of reflection.  Should it =
reveal
>> details internal to how PHP works on the inside or should it reflect =
the way PHP presents it as options?
>>=20
>> Did I miss anything?
>>=20
>>=20
>> I will come up with some way for people to vote on the issues at hand =
and we can cast our votes and be done with it, then I will
>> finish the project and get it out the door.
>>=20
>> -Clint