Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112100
Message-ID: <509731F7-85F1-4845-8425-7238BD998250@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_E19B3952-F8A1-4E16-836E-7AB79D544A71"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Thu, 22 Oct 2020 01:05:49 -0400
In-Reply-To: <11124061-cfeb-4668-8a8d-a11aa683477a@www.fastmail.com>
Cc: php internals <internals@lists.php.net>
To: Larry Garfield <larry@garfieldtech.com>
References: <eb143f8b-b242-47bb-9858-e6150dd7aea4@www.fastmail.com>
 <41AA7084-18F3-431B-B135-46C44FC26D1E@newclarity.net>
 <11124061-cfeb-4668-8a8d-a11aa683477a@www.fastmail.com>
Subject: Re: [PHP-DEV] [RFC] Short-function syntax
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_E19B3952-F8A1-4E16-836E-7AB79D544A71
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On Oct 21, 2020, at 8:50 AM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> On Tue, Oct 20, 2020, at 11:08 PM, Mike Schinkel wrote:
>>> On Oct 20, 2020, at 2:19 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>>>=20
>>> A while back, Nikita mentioned that it should now be easy to offer =
an abbreviated syntax for functions that are just a single expression.  =
I decided to take a crack at it and it turns out he was right.  I thus =
offer this RFC:
>>>=20
>>> https://wiki.php.net/rfc/short-functions
>>>=20
>>> Hopefully I made a decent enough case for it.  It's entirely a =
convenience factor, but I think for many OOP cases (getter methods and =
factored out operations) and functional cases (where functions should =
generally be a single expression conceptually) it does make the code =
nicer, more compact, and more readable.
>>=20
>> Simple and elegant.  I like it.
>>=20
>> I have two comments, but not about the feature. =20
>>=20
>> One comment is about the RFC itself, and the other is about a =
use-case=20
>> used to justify the feature that could warrant its own bespoke =
feature.
>>=20
>>=20
>> 1. The section on "Conditional methods" is really just an argument=20
>> about the benefits of encapsulating complex logic into well-named=20
>> functions as you could achieve exactly the same benefit with the=20
>> existing function syntax.  It does not appear to me that it provides=20=

>> any specific justification for the feature in the RFC. Should it =
really=20
>> be part of the RFC?
>=20
> In pre-RFC discussion, one of the pushbacks I got was "pfft, how =
common are single-line methods anyway?"  That example is mainly to =
demonstrate "quite common, actually, in fact common refactoring patterns =
tend to produce them a lot."  It's not the refactoring itself that =
benefits, per se, as it is the refactoring technique produces functions =
that would benefit from it.

Thank you for clarifying. I understand now why you included that =
section.

I think the problem I had understanding the section's purpose was the =
construction of the first sentence where "common refactoring technique" =
was its subject. =20

May I propose you consider a different construction that focuses on the =
frequency with which single-expression functions are needed? Here is but =
one such potential alternate:

-----
"One might ask how commonly we need single-expression functions? =
Consider the "if," "switch" and "while" statements. When their =
expressions are complex, we can add clarity by encapsulating into a =
single-expression function:"
-----

Also it might be good to rename the section "Conditional methods" to =
something like "Use-case frequency" to focus on the reason for =
inclusion, or if the purpose of the heading needs to be about how it =
would be used in the language then maybe "Control Flow Statement =
Expressions" would be more appropriate?

Anyway, just offering these suggestion in hopes that ensuring your RFC =
is as clear as it can be will make it more likely to pass.

-Mike

>=20
>> 2. In the section "Decorating functions in live code" where you state=20=

>> "Often times, methods exist that are just delegating to some other=20
>> method, either in the same object or a composed object." I think we=20=

>> could see great benefit from explicitly building delegation into=20
>> classes much like how Go provides type embedding[1]. For PHP, =
extending=20
>> the syntax for traits could be used to support delegation of one =
class=20
>> to another embedded class. Can you see this as a potential feature?
>>=20
>> -Mike
>=20
> I'd be in favor of some kind of automated "delegate this interface's =
methods to this object property" syntax, although that is unrelated to =
the RFC at hand.
>=20
> --Larry Garfield


--Apple-Mail=_E19B3952-F8A1-4E16-836E-7AB79D544A71--