Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97449
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain telia.com from 81.236.60.156 cause and error)
To: Larry Garfield <larry@garfieldtech.com>,
 Nikita Popov <nikita.ppv@gmail.com>
References: <6d4632cb-93b3-4237-a803-6b7ec13dae4a@Spark>
 <d482e3f5-0caf-1e3e-273a-e198ea5267c0@garfieldtech.com>
Cc: PHP internals <internals@lists.php.net>
Message-ID: <797a9b95-cb88-d19a-b8ef-bd44097c0bae@telia.com>
Date: Wed, 21 Dec 2016 10:38:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <d482e3f5-0caf-1e3e-273a-e198ea5267c0@garfieldtech.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: =?UTF-8?Q?Re:_[PHP-DEV]_Revisit_RFC_=e2=80=9cProperty_Accessors_Syn?=
 =?UTF-8?Q?tax_1.2=e2=80=9d?=
From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)

Hi,

This RFC was done close to 4 years ago when PHP 7 was not on
the table. So, I wonder if the performance implications are the
same, now that there is a new flashy PHP 7 engine?

Regards //Björn Larsson

Den 2016-12-19 kl. 23:47, skrev Larry Garfield:

> On 12/19/2016 02:57 PM, ilija.tovilo@me.com wrote:
>> Hi everyone
>>
>> There was an RFC about a C#-like property syntax almost four years 
>> 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 
>> this feature as it would make the language much more expressive. Let 
>> me start by defining the problem. First of all, almost all PHP 
>> frameworks hide their variables behind getters and setters. Here are 
>> some of the reasons why that is a good idea, I’m 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 well:
>>
>> - Large boilerplate for normal getters/setters
>> - Inconsistent syntax for reading/writing data
>>      - Calling a method for setting data instead of using the more 
>> intuitive `=` operator
>>      - Calling a method for accessing foreign variables while 
>> accessing private variables directly
>> - Inability to use built in assignment operators like .=, +=, -=, etc.
>> - Disregard of the DRY principle
>>
>> The positives clearly outweigh the negatives as they are mostly 
>> syntactical. 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, abandoning getters and setters is no option 
>> for anyone. Nonetheless, the RFC I linked above offers a way to get 
>> rid of the negatives without sacrificing any of the positives.
>>
>> Are there still any people who would like to see this happening just 
>> as much as I do?
>> I’m wondering if some of the people who have voted against the RFC 
>> might have changed their opinion or vice versa.
>>
>> Many thanks for reading!
>>
>> 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 
> even possible), that person would make a lot of devs (including me) 
> very very happy.  I am, sadly, not such a person.
>
> --Larry Garfield
>