Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113753
MIME-Version: 1.0
References: <44ac7866-75ef-44ab-a5f9-4e571652b5e6@www.fastmail.com> <21C66BCC-A77D-48B0-A653-9D65ADF06A3B@newclarity.net>
In-Reply-To: <21C66BCC-A77D-48B0-A653-9D65ADF06A3B@newclarity.net>
Reply-To: Levi Morrison <levi.morrison@datadoghq.com>
Date: Wed, 24 Mar 2021 21:22:52 -0600
Message-ID: <CAAKU0u=E7n5Y7H68cKBjGyv82yOsRe0+C2w6Ef=EsM-SaBu=Bg@mail.gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Short functions, take 2
From: internals@lists.php.net ("Levi Morrison via internals")

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> wr=
ote:
> >
> > 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 e=
ncourage functions to be written an in "expression style", that is, as actu=
al functions and not procedures.  As the RFC notes, such use cases are incr=
easing, and is likely to increase in PHP, and that's overall a good thing f=
or 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 conci=
se it does not do anything to reduce the (IMO overly) verbose nature of met=
hod declarations that require both a visibility modifier and the function k=
eyword. And while I know you just stated that conciseness in not a main goa=
l, 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 co=
uld be addressed in another RFC, but it could also be addressed in this one=
 =E2=80=94 assuming there was a will do to so =E2=80=94 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.