Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97443
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain me.com designates 17.172.80.97 as permitted sender)
Date: Mon, 19 Dec 2016 21:57:27 +0100
To: internals@lists.php.net
Message-ID: <6d4632cb-93b3-4237-a803-6b7ec13dae4a@Spark>
MIME-version: 1.0
Content-type: multipart/alternative; boundary=58584a6a_6b8b4567_25c
Subject: Revisit RFC =?utf-8?Q?=E2=80=9CProperty_?=Accessors Syntax
 =?utf-8?Q?1.2=E2=80=9D?=
From: ilija.tovilo@me.com

--58584a6a_6b8b4567_25c
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi everyone

There was an R=46C about a C=23-like property syntax almost four years ag=
o that got declined:
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2

It failed by only 2-3 votes. In my opinion, PHP is still in need of this =
feature as it would make the language much more expressive. Let me start =
by defining the problem. =46irst of all, almost all PHP frameworks hide t=
heir variables behind getters and setters. Here are some of the reasons w=
hy that is a good idea, I=E2=80=99m sure there are many more:

- Ability to sanitize input
- Ability to lazily load data when requested (getter was called)
- Ability to expose only getter or setter publicly
- Easily mockable accessors for unit tests
- Ability to execute arbitrary code when accessors are called
- Modifiable business logic without breaking the API

Here are some of the negatives, though there are probably more here as we=
ll:

- Large boilerplate for normal getters/setters
- Inconsistent syntax for reading/writing data
=C2=A0 =C2=A0 - Calling a method for setting data instead of using the mo=
re intuitive =60=3D=60 operator
=C2=A0 =C2=A0 - Calling a method for accessing foreign variables while ac=
cessing private variables directly
- Inability to use built in assignment operators like .=3D, +=3D, -=3D, e=
tc.
- Disregard of the DRY principle

The positives clearly outweigh the negatives as they are mostly syntactic=
al. This is probably why using getters/setters everywhere has been a good=
-enough solution for such a long time. Because of that, just like the pos=
itives, the negatives have become a part of the language. Clearly, abando=
ning getters and setters is no option for anyone. Nonetheless, the R=46C =
I linked above offers a way to get rid of the negatives without sacrifici=
ng any of the positives.

Are there still any people who would like to see this happening just as m=
uch as I do=3F
I=E2=80=99m wondering if some of the people who have voted against the R=46=
C might have changed their opinion or vice versa.

Many thanks for reading=21

Regards,
Ilija


--58584a6a_6b8b4567_25c--