Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97446
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain me.com designates 17.172.80.95 as permitted sender)
Date: Tue, 20 Dec 2016 00:02:05 +0100
To: Larry Garfield <larry@garfieldtech.com>
Cc: internals@lists.php.net
Message-ID: <dac2004c-c137-4531-b658-4ebc6314b47d@Spark>
In-reply-to: <d482e3f5-0caf-1e3e-273a-e198ea5267c0@garfieldtech.com>
References: <6d4632cb-93b3-4237-a803-6b7ec13dae4a@Spark>
 <d482e3f5-0caf-1e3e-273a-e198ea5267c0@garfieldtech.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary=58586710_327b23c6_25c
Subject: Re: [PHP-DEV] Revisit RFC =?utf-8?Q?=E2=80=9CProperty_?=Accessors
 Syntax =?utf-8?Q?1.2=E2=80=9D?=
From: ilija.tovilo@me.com

--58586710_327b23c6_25c
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I see, that makes a lot of sense. Sadly, I am neither a C developer nor d=
o I understand the PHP interpreter codebase in the slightest.
At least I now understand why the R=46C was rejected, maybe that will com=
fort me when I cry myself to sleep tonight :P


On 19 Dec 2016, 23:47 +0100, Larry Garfield <larry=40garfieldtech.com>, w=
rote:
> On 12/19/2016 02:57 PM, ilija.tovilo=40me.com wrote:
> > Hi everyone
> >
> > There was an R=46C about a C=23-like property syntax almost four year=
s ago 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 t=
his feature as it would make the language much more expressive. Let me st=
art by defining the problem. =46irst of all, almost all PHP frameworks hi=
de their variables behind getters and setters. Here are some of the reaso=
ns why 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 a=
s well:
> >
> > - Large boilerplate for normal getters/setters
> > - Inconsistent syntax for reading/writing data
> > - Calling a method for setting data instead of using the more intuiti=
ve =60=3D=60 operator
> > - Calling a method for accessing foreign variables while accessing pr=
ivate variables directly
> > - Inability to use built in assignment operators like .=3D, +=3D, -=3D=
, etc.
> > - Disregard of the DRY principle
> >
> > The positives clearly outweigh the negatives as they are mostly synta=
ctical. 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=
 positives, the negatives have become a part of the language. Clearly, ab=
andoning getters and setters is no option for anyone. Nonetheless, the R=46=
C I linked above offers a way to get rid of the negatives without sacrifi=
cing any of the positives.
> >
> > Are there still any people who would like to see this happening just =
as much as I do=3F
> > I=E2=80=99m wondering if some of the people who have voted against th=
e R=46C might have changed their opinion or vice versa.
> >
> > Many thanks for reading=21
> >
> > Regards,
> > Ilija
>
> As I understand it from those involved, most people did want that
> feature. I still do. :-) However, there is as of yet no confirmed way
> to add it without more of a performance hit than many folks are willing=

> to accept. That is, it's not the concept people object to, just the
> implementation.
>
> If someone can figure out how to make that work with a small enough
> performance hit (where 0 would be ideal, but I don't know if that's eve=
n
> possible), that person would make a lot of devs (including me) very ver=
y
> happy. I am, sadly, not such a person.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--58586710_327b23c6_25c--