Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:97450 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 74778 invoked from network); 21 Dec 2016 13:19:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Dec 2016 13:19:11 -0000 Authentication-Results: pb1.pair.com header.from=ilija.tovilo@me.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ilija.tovilo@me.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain me.com designates 17.172.220.113 as permitted sender) X-PHP-List-Original-Sender: ilija.tovilo@me.com X-Host-Fingerprint: 17.172.220.113 st11p02im-asmtp001.me.com Linux 2.6 Received: from [17.172.220.113] ([17.172.220.113:54009] helo=st11p02im-asmtp001.me.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 30/5F-36089-A418A585 for ; Wed, 21 Dec 2016 08:19:08 -0500 Received: from process-dkim-sign-daemon.st11p02im-asmtp001.me.com by st11p02im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OIJ00000CKBIR00@st11p02im-asmtp001.me.com> for internals@lists.php.net; Wed, 21 Dec 2016 13:19:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1482326343; bh=7hUGB+QsI4mMmI1/aEC9wkz8JE0oZBsxSkEAHXcXZ1Y=; h=MIME-version:Content-type:To:From:Subject:Date:Message-id; b=aADmbHhmEILAV2U5KUYT3llYKaFnClYnO5nWy+O9GBB5w6P4hYmF8r22v79cjVCpR T61QM5oxga6Mfqa0VmFoxg6nUlJLfAUr74LMq1eFzaOr7ivEla/w9HLaI0SfLQ8Ue4 8M06z8WOO0JBnxmWPayoAw3CxtcAot2+urzNcZBopgvXqO5opO7siy2a8mpCh2mr8N 0l3oZTPr4IYBL+41FVki/X6E5fj09/PbAwenK7J9peaEqJWrszxcyKjlJ/ffrTJtHz 4r3uoQCpecUoTjZ+VGX0+CquzoI12ZYPS98H8ai+cs8IVAWYouK/Hbj91m4s6vx250 RzTjCDTK4RWdg== Received: from st11p02im-spool002.me.com ([17.172.220.214]) by st11p02im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTP id <0OIJ006N0EBOEG40@st11p02im-asmtp001.me.com>; Wed, 21 Dec 2016 13:19:02 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-12-21_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1612210215 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_2G+GP2jBTtE6BJutoOupMw)" Received: from localhost ([17.172.220.222]) by st11p02im-spool002.mac.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTP id <0OIJ01713EBPY990@st11p02im-spool002.mac.com>; Wed, 21 Dec 2016 13:19:01 +0000 (GMT) To: =?utf-8?B?QmrDtnJuIExhcnNzb24=?= Cc: Larry Garfield , Nikita Popov , PHP internals Date: Wed, 21 Dec 2016 13:18:59 +0000 (GMT) X-Mailer: iCloud MailClient16HHotfix3 MailServer16H91.25712-16A-1566-de436d2ed559 X-Originating-IP: [213.221.233.50] Message-ID: Subject: =?utf-8?B?UmU6IFtQSFAtREVWXSBSZXZpc2l0IFJGQyDigJxQcm9wZXJ0eSBBY2Nlc3Nv?= =?utf-8?B?cnMgU3ludGF4IDEuMuKAnQ==?= From: ilija.tovilo@me.com (Ilija Tovilo) --Boundary_(ID_2G+GP2jBTtE6BJutoOupMw) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Now that PHP 7 is here, one step backwards (performance wise) might not ma= tter as much as it did before. Others might still disagree though.=0A=0A=0A= =0AI'd be interesting to hear if the people who voted against the RFC beca= use of the performance penalty still feel the same now that PHP 7 is here.= =0A=0A=0A=0ARegards=0A=0A=0AOn 21 Dec, 2016, at 10:38 AM, Bj=C3=B6rn Larss= on wrote:=0A=0A=0AHi,=0A=0AThis RFC was done c= lose to 4 years ago when PHP 7 was not on=0Athe table. So, I wonder if the= performance implications are the=0Asame, now that there is a new flashy P= HP 7 engine?=0A=0ARegards //Bj=C3=B6rn Larsson=0A=0ADen 2016-12-19 kl. 23:= 47, skrev Larry Garfield:=0A=0A=0AOn 12/19/2016 02:57 PM, ilija.tovilo@me.= com wrote:=0AHi everyone=0A=0A=0AThere was an RFC about a C#-like property= syntax almost four years=0Aago that got declined:=0Ahttps://wiki.php.net/= rfc/propertygetsetsyntax-v1.2=0A=0A=0A=0AIt failed by only 2-3 votes. In m= y opinion, PHP is still in need of=0Athis feature as it would make the lan= guage much more expressive. Let=0Ame start by defining the problem. First = of all, almost all PHP=0Aframeworks hide their variables behind getters an= d setters. Here are=0Asome of the reasons why that is a good idea, I=E2=80= =99m sure there are many=0Amore:=0A=0A=0A- Ability to sanitize input=0A- A= bility to lazily load data when requested (getter was called)=0A- Ability = to expose only getter or setter publicly=0A- Easily mockable accessors for= unit tests=0A- Ability to execute arbitrary code when accessors are calle= d=0A- Modifiable business logic without breaking the API=0A=0A=0AHere are = some of the negatives, though there are probably more here=0Aas well:=0A=0A= =0A- Large boilerplate for normal getters/setters=0A- Inconsistent syntax = for reading/writing data=0A- Calling a method for setting data instead of = using the more=0Aintuitive `=3D` operator=0A- Calling a method for accessi= ng foreign variables while=0Aaccessing private variables directly=0A- Inab= ility to use built in assignment operators like .=3D, +=3D, -=3D, etc.=0A-= Disregard of the DRY principle=0A=0A=0AThe positives clearly outweigh the= negatives as they are mostly=0Asyntactical. This is probably why using ge= tters/setters everywhere=0Ahas been a good-enough solution for such a long= time. Because of=0Athat, just like the positives, the negatives have beco= me a part of=0Athe language. Clearly, abandoning getters and setters is no= option=0Afor anyone. Nonetheless, the RFC I linked above offers a way to = get=0Arid of the negatives without sacrificing any of the positives.=0A=0A= =0AAre there still any people who would like to see this happening just=0A= as much as I do?=0AI=E2=80=99m wondering if some of the people who have vo= ted against the RFC=0Amight have changed their opinion or vice versa.=0A=0A= =0AMany thanks for reading!=0A=0A=0ARegards,=0AIlija=0A=0A=0AAs I understa= nd it from those involved, most people did want that=0Afeature. I still do= . :-) However, there is as of yet no confirmed=0Away to add it without mor= e of a performance hit than many folks are=0Awilling to accept. That is, i= t's not the concept people object to,=0Ajust the implementation.=0A=0A=0AI= f someone can figure out how to make that work with a small enough=0Aperfo= rmance hit (where 0 would be ideal, but I don't know if that's=0Aeven poss= ible), that person would make a lot of devs (including me)=0Avery very hap= py. I am, sadly, not such a person.=0A=0A=0A--Larry Garfield=0A=0A=0A=0A=0A= --=0APHP Internals - PHP Runtime Development Mailing List=0ATo unsubscribe= , visit: http://www.php.net/unsub.php=0A=0A= --Boundary_(ID_2G+GP2jBTtE6BJutoOupMw) Content-type: multipart/related; boundary="Boundary_(ID_sRRRz19l9FMfbwKv8yOADw)"; type="text/html" --Boundary_(ID_sRRRz19l9FMfbwKv8yOADw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
Now that PHP 7 is here, one step backwards (performance wise) might n= ot matter as much as it did before. Others might still disagree though.

I'd be interesting to hear= if the people who voted against the RFC because of the performance penalt= y still feel the same now that PHP 7 is here.

Regards

On 21 Dec, 2016, at 10:38 AM, Bj=C3=B6rn Larsson <bjorn= .x.larsson@telia.com> wrote:

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
s= ame, now that there is a new flashy PHP 7 engine?

Regards //Bj=C3=B6= rn Larsson

Den 2016-12-19 kl. 23:47, skrev Larry Garfield:

<= blockquote type=3D"cite" class=3D"quoted-plain-text">On 12/19/2016 02:57 P= M, 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/prope= rtygetsetsyntax-v1.2

It failed by only 2-3 votes. In my opinion, PHP i= s still in need of
this feature as it would make the language much more expressive. Let
me start by defi= ning the problem. First of all, almost all PHP
frameworks hide their variables behind get= ters and setters. Here are
some of the reasons why that is a good idea, I=E2=80=99m sure = there are many
= more:

- Ability to saniti= ze input
- Abil= ity to lazily load data when requested (getter was called)
- Ability to expose only gette= r 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 da= ta
- Calling a = method for setting data instead of using the more
intuitive `=3D` operator
- Calling a method for access= ing foreign variables while
accessing private variables directly
- Inability to use built in assignment = operators like .=3D, +=3D, -=3D, etc.
- Disregard of the DRY principle

The positives clearly outweigh the negative= s 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 negat= ives have become a part of
the language. Clearly, abandoning getters and setters is no op= tion
for anyone= . Nonetheless, the RFC I linked above offers a way to get
rid of the negatives without sa= crificing any of the positives.

Are there still any people who would like to see this happening just<= /blockquote>
as much as I do= ?
I=E2=80=99m w= ondering if some of the people who have voted against the RFC
=
might have changed their op= inion or vice versa.

Many= thanks for reading!

Rega= rds,
Ilija

As= I understand it from those involved, most people did want that
feature. I still d= o. :-) However, there is as of yet no confirmed
way to add it without more of a pe= rformance 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 w= ith a small enough
performance hit (where 0 would be ideal, but I don't know if th= at's
eve= n possible), that person would make a lot of devs (including me)
very very 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

= --Boundary_(ID_sRRRz19l9FMfbwKv8yOADw)-- --Boundary_(ID_2G+GP2jBTtE6BJutoOupMw)--