Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113752
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
In-Reply-To: <44ac7866-75ef-44ab-a5f9-4e571652b5e6@www.fastmail.com>
Date: Wed, 24 Mar 2021 22:02:05 -0400
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <21C66BCC-A77D-48B0-A653-9D65ADF06A3B@newclarity.net>
References: <44ac7866-75ef-44ab-a5f9-4e571652b5e6@www.fastmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Subject: Re: [PHP-DEV] [RFC] Short functions, take 2
From: mike@newclarity.net (Mike Schinkel)

> On Mar 24, 2021, at 8:39 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> As requested, splitting off the short-functions RFC to its own thread.
>=20
> https://wiki.php.net/rfc/short-functions
>=20
> 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. =20

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. =20=


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 =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.


>=20
> 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.
>=20
> --=20
>  Larry Garfield
>  larry@garfieldtech.com
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>=20