# Revisit RFC “Property Accessors Syntax 1.2” - Thread: https://externals.io/message/97443 - Original archive: https://news-web.php.net/php.internals/97443 - Started by ilija.tovilo@me.com on 2016-12-19T20:57:27+00:00 - Messages: 5 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #97443 — ilija.tovilo@me.com — 2016-12-19T20:57:27+00:00 URL: https://externals.io/message/97443#97443 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 --- ## #97444 — michal@brzuchalski.com — 2016-12-19T22:29:39+00:00 URL: https://externals.io/message/97443#97444 · In reply to: #97443 Hi Ilija, I have no vote rights, but this one is on my "Nice To Have Features in PHP" list too. +1 for property getters/setters Cheers, 2016-12-19 21:57 GMT+01:00 : > 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 > > -- regards / pozdrawiam, -- Michał Brzuchalski about.me/brzuchal brzuchalski.com --- ## #97445 — Larry Garfield — 2016-12-19T22:47:21+00:00 URL: https://externals.io/message/97443#97445 · In reply to: #97443 > 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 --- ## #97446 — ilija.tovilo@me.com — 2016-12-19T23:02:05+00:00 URL: https://externals.io/message/97443#97446 · In reply to: #97445 I see, that makes a lot of sense. Sadly, I am neither a C developer nor do I understand the PHP interpreter codebase in the slightest. At least I now understand why the RFC was rejected, maybe that will comfort me when I cry myself to sleep tonight :P > > > […] > > 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 --- ## #97449 — bjorn.x.larsson@telia.com — 2016-12-21T09:38:17+00:00 URL: https://externals.io/message/97443#97449 · In reply to: #97445 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: > > > […] > > 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