Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63346
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ez.no designates 65.55.88.15 as permitted sender)
Received-SPF: pass (mail265-tx2: domain of ez.no designates 157.56.249.213 as permitted sender) client-ip=157.56.249.213; envelope-from=andre.romcke@ez.no; helo=AM2PRD0710HT003.eurprd07.prod.outlook.com ;.outlook.com ;
To: Clint Priest <cpriest@zerocue.com>
CC: Jazzer Dane <tbprogrammer@gmail.com>, "internals@lists.php.net"
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Propety Accessors v1.1
Thread-Index: Ac2lRqaw0wLAVcGGQAyyWuaNO91x4QASet+AAASYmYAAAETXgAAAKxEAAAWM04AABBwsAAAJtrUAAAEUaoAAVHcUgAADlLiAAAFw9IAAEqnCAA==
Date: Thu, 11 Oct 2012 11:54:08 +0000
Message-ID: <D8A22EB1-E0DA-4691-ABBE-445D53AFFE6F@ez.no>
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>
 <CACxA8bnqc4L56AxSVHQJgaT3UFOCSc93NdmE_W6CdERa+rK5Gw@mail.gmail.com>
 <9570D903A3BECE4092E924C2985CE485612B4F63@MBX202.domain.local>
In-Reply-To: <9570D903A3BECE4092E924C2985CE485612B4F63@MBX202.domain.local>
Accept-Language: nb-NO, de-DE, en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <323281EECC7DCE49AE405CE01375209D@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
From: andre.romcke@ez.no (=?iso-8859-1?Q?Andr=E9_R=F8mcke?=)

On Oct 11, 2012, at 4:59 AM, Clint Priest <cpriest@zerocue.com> wrote:

> Why is everyone so dead set against read-only and write-only?
>=20
> I could not disagree more with you on what is "pretty" and "readable".
>=20
> To me:
>=20
> public read-only $hours {
>                get { ... }
> }
>=20
> Is infinitely more readable and understandable than:
>=20
> public $hours {
>                get() { ... }
>                private final set($value) { ... }
> }
>=20
> The latter implies that it can be "set" within the right context (interna=
lly to the class), which is precisely the opposite of what is desired (read=
 only).


If it can be used on normal properties as well (w/o the overhead of functio=
n calls) then: +1
Otherwise it would not be consistent to introduce it.

On the topic of consistency, could not see any other keyword in php that us=
es hyphen in it.


>=20
> From: Jazzer Dane [mailto:tbprogrammer@gmail.com]
> Sent: Wednesday, October 10, 2012 9:18 PM
> To: Clint Priest
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
>=20
> This all sounds about right.
>=20
> In regards to #4 - read-only/write-only:
> I think that, from a "pretty syntax" point of view, private final set() {=
} and private final get() {} are definitely our best bets. But... from a lo=
gical point of view, I prefer read-only/write-only.
>=20
> private final get() {} is technically saying it will always return null.
> private final set() {} is technically saying that setting doesn't do anyt=
hing - but it still works.
>=20
> But I don't see any sane scenario where someone would want to do the abov=
e. Therefore, it may just be best to use them in place of the currently pro=
posed read-only/write-only.
> On Wed, Oct 10, 2012 at 5:35 PM, Clint Priest <cpriest@zerocue.com<mailto=
:cpriest@zerocue.com>> wrote:
> Okay, I would like this to be the last time there are revisions to this R=
FC.
>=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 d=
irectly, 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 opt=
ions?
>=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
>=20