Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63339
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <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> <9570D903A3BECE4092E924C2985CE485612B4F63@MBX202.domain.local>
Date: Wed, 10 Oct 2012 22:46:15 -0700
Message-ID: <CACxA8bkrh7DLehXmS30QUQpb3zQa0inNKTVzMOD_2KHZYkQhQw@mail.gmail.com>
To: Clint Priest <cpriest@zerocue.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0442879e1ddb6d04cbc21804
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
From: tbprogrammer@gmail.com (Jazzer Dane)

--f46d0442879e1ddb6d04cbc21804
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

If at all possible, I'd rather not add extra keywords such as read-only and
write-only to the language. If it's unnecessary than it shouldn't be done -
that's my point of view. The question is thus "is read-only necessary?".
The proposal brought up by someone else was using

> private final set($value) {}
>
and

> private final get() {}
>
With no code in-between the braces, the functions are not accessible, not
extensible, and pointless. Thus we could arguably use them as alternatives
to the proposed read/write-only syntax.
But, in my previous emai,l I brought up the fact that this proposal isn't
that logically sound. The above lines of code don't exactly mean that
get/set aren't allowed... but at the same time, I don't know of any
scenarios where a developer would want to use private final get/set wherein
null is always returned or nothing is ever set.

The fact that this proposal is consistent with the language is a plus to
me. But I don't think it's enough - I don't like the logical
inconsistencies it brings.

If I were to vote between the two as to which gets implemented into PHP, I
would probably lean towards read/write-only, but I'm not a fan of either.
In the end, we need it to be logical. Good looking, consistent syntax is
nice, but having something behave even a little bit illogically is not at
all okay.

On Wed, Oct 10, 2012 at 7:59 PM, Clint Priest <cpriest@zerocue.com> wrote:

>  Why is everyone so dead set against read-only and write-only?****
>
> ** **
>
> I could not disagree more with you on what is =93pretty=94 and =93readabl=
e=94.****
>
> ** **
>
> To me:****
>
> ** **
>
> public read-only $hours {****
>
>                 get { =85 }****
>
> }****
>
> ** **
>
> Is infinitely more readable and understandable than:****
>
> ** **
>
> public $hours {****
>
>                 get() { ... }****
>
>                 private final set($value) { =85 }****
>
> }****
>
> ** **
>
> The latter implies that it can be =93set=94 within the right context
> (internally to the class), which is precisely the opposite of what is
> desired (read only).****
>
> ** **
>
> *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
> logical 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
> anything - 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 current=
ly
> proposed read-only/write-only.****
>
>  On Wed, Oct 10, 2012 at 5:35 PM, Clint Priest <cpriest@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
> of contention:
>
> 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 everyon=
e.
> 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?
>
> Did I miss anything?
>
>
> 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.
>
> -Clint****
>
> ** **
>

--f46d0442879e1ddb6d04cbc21804--