Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63336
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: Jazzer Dane <tbprogrammer@gmail.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Propety Accessors v1.1
Thread-Index: AQHNpfaE0wLAVcGGQAyyWuaNO91x4ZezPRQAgABndID//8fU0A==
Date: Thu, 11 Oct 2012 02:59:45 +0000
Message-ID: <9570D903A3BECE4092E924C2985CE485612B4F63@MBX202.domain.local>
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>
In-Reply-To: <CACxA8bnqc4L56AxSVHQJgaT3UFOCSc93NdmE_W6CdERa+rK5Gw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_9570D903A3BECE4092E924C2985CE485612B4F63MBX202domainloc_"
MIME-Version: 1.0
Subject: RE: [PHP-DEV] [RFC] Propety Accessors v1.1
From: cpriest@zerocue.com (Clint Priest)

--_000_9570D903A3BECE4092E924C2985CE485612B4F63MBX202domainloc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Why is everyone so dead set against read-only and write-only?

I could not disagree more with you on what is "pretty" and "readable".

To me:

public read-only $hours {
                get { ... }
}

Is infinitely more readable and understandable than:

public $hours {
                get() { ... }
                private final set($value) { ... }
}

The latter implies that it can be "set" within the right context (internall=
y to the class), which is precisely the opposite of what is desired (read o=
nly).

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

This all sounds about right.

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 logi=
cal point of view, I prefer read-only/write-only.

private final get() {} is technically saying it will always return null.
private final set() {} is technically saying that setting doesn't do anythi=
ng - but it still works.

But I don't see any sane scenario where someone would want to do the above.=
 Therefore, it may just be best to use them in place of the currently propo=
sed read-only/write-only.
On Wed, Oct 10, 2012 at 5:35 PM, Clint Priest <cpriest@zerocue.com<mailto:c=
priest@zerocue.com>> wrote:
Okay, I would like this to be the last time there are revisions to this RFC=
.

To sum up the last few days of conversations, I have these down as points o=
f contention:

1.  Accessor functions should not be present on the object and callable dir=
ectly, for example, $o->__getHours() should not be allowed.
2.  Preferred syntax for accessors should be "public set($value) { ... }" w=
ith no "magic" $value (with possible type hinting)
3.  Automatically implemented get; set; with auto-backing field should be e=
liminated 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 i=
s 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 fo=
r accessors
6.  The "truth" of reflection.  Should it reveal details internal to how PH=
P works on the inside or should it reflect the way PHP presents it as optio=
ns?

Did I miss anything?


I will come up with some way for people to vote on the issues at hand and w=
e can cast our votes and be done with it, then I will finish the project an=
d get it out the door.

-Clint


--_000_9570D903A3BECE4092E924C2985CE485612B4F63MBX202domainloc_--