Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Short functions, take 2 »

[RFC] Short functions, take 2

php.internals

Larry Garfield

5 years ago
As requested, splitting off the short-functions RFC to its own thread. https://wiki.php.net/rfc/short-functions In response to the feedback that the savings in typing volume is small, that's true but also not the main point. The main point is to allow and encourage functions to be written an in "expression style", that is, as actual functions and not procedures. As the RFC notes, such use cases are increasing, and is likely to increase in PHP, and that's overall a good thing for the language. It fits well with a number of recent RFCs both passed and proposed, and makes writing functional-style code much more natural. PSR-12 may be unnecessarily verbose (I dislike PSR-12 myself, and have made no secret of that), but it is far and away the most widely used coding standard in PHP land so we cannot ignore its influence.
-- Larry Garfield larry@garfieldtech.com

Mike Schinkel

5 years ago
> On Mar 24, 2021, at 8:39 PM, Larry Garfield <larry@garfieldtech.com> wrote: > > As requested, splitting off the short-functions RFC to its own thread. > > https://wiki.php.net/rfc/short-functions > > In response to the feedback that the savings in typing volume is small, that's true but also not the main point. The main point is to allow and encourage functions to be written an in "expression style", that is, as actual functions and not procedures. As the RFC notes, such use cases are increasing, and is likely to increase in PHP, and that's overall a good thing for the language. It fits well with a number of recent RFCs both passed and proposed, and makes writing functional-style code much more natural.
I like it. I hope this passes, and would vote for it if I had a vote. -Mike P.S. I do find myself lamenting that while this FRC makes code more concise it does not do anything to reduce the (IMO overly) verbose nature of method declarations that require both a visibility modifier and the function keyword. And while I know you just stated that conciseness in not a main goal, it is still a benefit of this proposal. It would be much nicer if we could indicate in fewer characters what the visibility modifier and the function keyword currently denote. Yes, that could be addressed in another RFC, but it could also be addressed in this one — assuming there was a will do to so — so now felt like a good a time as any to bring it up. Assuming others besides just me would like to see function signatures be made less verbose and would like to see some proposed alternatives, please ask and I will happily follow up with some ideas.

Unnamed Person

5 years ago
On Wed, Mar 24, 2021 at 8:02 PM Mike Schinkel <mike@newclarity.net> wrote:
> > > On Mar 24, 2021, at 8:39 PM, Larry Garfield <larry@garfieldtech.com> wrote: > > > > As requested, splitting off the short-functions RFC to its own thread. > > > > https://wiki.php.net/rfc/short-functions > > > > In response to the feedback that the savings in typing volume is small, that's true but also not the main point. The main point is to allow and encourage functions to be written an in "expression style", that is, as actual functions and not procedures. As the RFC notes, such use cases are increasing, and is likely to increase in PHP, and that's overall a good thing for the language. It fits well with a number of recent RFCs both passed and proposed, and makes writing functional-style code much more natural. > > I like it. > > I hope this passes, and would vote for it if I had a vote. > > -Mike > > P.S. I do find myself lamenting that while this FRC makes code more concise it does not do anything to reduce the (IMO overly) verbose nature of method declarations that require both a visibility modifier and the function keyword. And while I know you just stated that conciseness in not a main goal, it is still a benefit of this proposal. > > It would be much nicer if we could indicate in fewer characters what the visibility modifier and the function keyword currently denote. Yes, that could be addressed in another RFC, but it could also be addressed in this one — assuming there was a will do to so — so now felt like a good a time as any to bring it up. > > Assuming others besides just me would like to see function signatures be made less verbose and would like to see some proposed alternatives, please ask and I will happily follow up with some ideas.
Drop "public", as it is unnecessary. I never understood why PSR-whatever decided to always require it, when not all projects agreed on that, and there are actual arguments to put it only when overriding visibility (you see it only when it matters). Anyway, it's not that important, as I don't have to do what PSR-whatever decided. Instead of writing this: ``` class A { public function method($arg1) { return expr($arg1); } } ``` I can write this: ``` class A { function method($arg1) { return expr($arg1); } } ``` To be quite honest, I like putting statements on a single line as long as they fit in whatever column limit the project uses. My .clang-format has been doing this for my C code and I've grown quite fond of it; there is real value in seeing more actual code on a page at a time, and I don't feel like it's too cramped.

Guilliam Xavier

5 years ago
On Thu, Mar 25, 2021 at 4:23 AM Levi Morrison via internals < internals@lists.php.net> wrote:
> [...] > Instead of writing this: > > ``` > class A > { > public function method($arg1) > { > return expr($arg1); > } > } > ``` > > I can write this: > > ``` > class A { > function method($arg1) { return expr($arg1); } > } > ``` >
For what it's worth (probably not much), when fiddling with quick test code samples (e.g. on 3v4l with "quick preview"), more than once I have written things like this: ``` class A { function method($arg1) { expr($arg1); } } ``` i.e. I initially forgot the "return " (and had to go back and add it). I would surely not have this problem anymore with this: ``` class A { function method($arg1) => expr($arg1); } ``` (It also seems I don't have this problem when writing a return on its own line :/) Regards,
-- Guilliam Xavier

Peter Stalman

5 years ago
On Wed, Mar 24, 2021 at 5:40 PM Larry Garfield <larry@garfieldtech.com> wrote:
> In response to the feedback that the savings in typing volume is small, > that's true but also not the main point. The main point is to allow and > encourage functions to be written an in "expression style", that is, as > actual functions and not procedures. As the RFC notes, such use cases are > increasing, and is likely to increase in PHP, and that's overall a good > thing for the language. It fits well with a number of recent RFCs both > passed and proposed, and makes writing functional-style code much more > natural. >
Hi Larry, I too am wondering about the space saving aspect; as Levi showed it's quite easy to currently write functions on one line, which really only cost 7 more characters. Overall though, I am not a fan of the code getting wider, and the return statements not lining up as I scroll down the code. As for the "expression style" argument, it's a valid one. However, I'm confused why you submitted this RFC hand-in-hand with the multi-statement auto-capture closures. Doesn't that contradict the single statement "expression style" argument? Overall, I'm not really that much against it, but my only worry is that while it is slightly less verbose it might create more cluttered code. Thanks, Peter P.S. I also don't like PSR-12. Allman braces and tabs for life.

Larry Garfield

5 years ago
On Thu, Mar 25, 2021, at 12:12 AM, Peter Stalman wrote:
> On Wed, Mar 24, 2021 at 5:40 PM Larry Garfield <larry@garfieldtech.com> > wrote: > > > In response to the feedback that the savings in typing volume is small, > > that's true but also not the main point. The main point is to allow and > > encourage functions to be written an in "expression style", that is, as > > actual functions and not procedures. As the RFC notes, such use cases are > > increasing, and is likely to increase in PHP, and that's overall a good > > thing for the language. It fits well with a number of recent RFCs both > > passed and proposed, and makes writing functional-style code much more > > natural. > > > > Hi Larry, > > I too am wondering about the space saving aspect; as Levi showed it's quite > easy to currently write functions on one line, which really only cost 7 > more characters. Overall though, I am not a fan of the code getting wider, > and the return statements not lining up as I scroll down the code.
In practice, I've found myself writing arrow functions on 2 lines a lot, like this: $f = fn($a, $b): int => $a * $b; I find that very readable, balances height vs width well, and it's a style very popular in functional languages. I expect a lot of short-function uses to do the same, which is a good place to end up.
> As for the "expression style" argument, it's a valid one. However, I'm > confused why you submitted this RFC hand-in-hand with the multi-statement > auto-capture closures. Doesn't that contradict the single statement > "expression style" argument?
The short-function RFC was originally written early last fall. I put it on hold because there was also on again/off again discussion of auto-capture closures and I was warned to avoid conflicting on the syntax. I only recently got around to connecting with Nuno, who had a PR sitting around for that he'd been ignoring for a while, too. :-) They're separate proposals with their own benefits. They were (re)-presented together mainly to demonstrate that yes, we did think through the syntax to ensure that they fit well together and didn't create confusion around what certain syntax combinations mean.
> Overall, I'm not really that much against it, but my only worry is that > while it is slightly less verbose it might create more cluttered code.
Try a lot of 2-line functions as above. I think you'll find it's actually quite nice in practice, which is what I'm going for.
> > Thanks, > Peter > > P.S. I also don't like PSR-12. Allman braces and tabs for life.
Same-line braces FTW, but don't talk to me about tabs. :-P --Larry Garfield

Larry Garfield

5 years ago
On Wed, Mar 24, 2021, at 7:39 PM, Larry Garfield wrote:
> As requested, splitting off the short-functions RFC to its own thread. > > https://wiki.php.net/rfc/short-functions > > In response to the feedback that the savings in typing volume is small, > that's true but also not the main point. The main point is to allow > and encourage functions to be written an in "expression style", that > is, as actual functions and not procedures. As the RFC notes, such use > cases are increasing, and is likely to increase in PHP, and that's > overall a good thing for the language. It fits well with a number of > recent RFCs both passed and proposed, and makes writing > functional-style code much more natural. > > PSR-12 may be unnecessarily verbose (I dislike PSR-12 myself, and have > made no secret of that), but it is far and away the most widely used > coding standard in PHP land so we cannot ignore its influence. > > -- > Larry Garfield > larry@garfieldtech.com
Hi folks. I've added a bit more reasoning to the short-functions RFC, so it's worth giving another read-over. It was also recently featured on an episode of PHP Internals if you want a more verbal case made. :-) Unless there is any significant feedback, I'll be calling a vote for this RFC sometime late this week (Thursday/Friday-ish). Cheers. --Larry Garfield

Илья Сомов

5 years ago
> Unless there is any significant feedback, I'll be calling a vote for this RFC sometime late this week (Thursday/Friday-ish).
Hi! As a regular PHP developer, I am very interested in having this quality-of-life feature: it allows code whose intent is more functional-ish (mapping input arguments to an output expression), than imperative-ish (do this then do that), to look more appropriate. Is it planned to be voted or it's just forgotten :P?