Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112085
Message-ID: <41AA7084-18F3-431B-B135-46C44FC26D1E@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_29739DE6-B4EE-4A4A-8A07-D4E922AFC4A3"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 21 Oct 2020 00:08:35 -0400
In-Reply-To: <eb143f8b-b242-47bb-9858-e6150dd7aea4@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>
Subject: Re: [PHP-DEV] [RFC] Short-function syntax
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_29739DE6-B4EE-4A4A-8A07-D4E922AFC4A3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> 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.

Simple and elegant.  I like it.

I have two comments, but not about the feature. =20

One comment is about the RFC itself, and the other is about a use-case =
used to justify the feature that could warrant its own bespoke feature.


1. The section on "Conditional methods" is really just an argument about =
the benefits of encapsulating complex logic into well-named functions as =
you could achieve exactly the same benefit with the existing function =
syntax.  It does not appear to me that it provides any specific =
justification for the feature in the RFC. Should it really be part of =
the RFC?

2. In the section "Decorating functions in live code" where you state =
"Often times, methods exist that are just delegating to some other =
method, either in the same object or a composed object." I think we =
could see great benefit from explicitly building delegation into classes =
much like how Go provides type embedding[1]. For PHP, extending the =
syntax for traits could be used to support delegation of one class to =
another embedded class. Can you see this as a potential feature?

-Mike


[1] https://travix.io/type-embedding-in-go-ba40dd4264df



--Apple-Mail=_29739DE6-B4EE-4A4A-8A07-D4E922AFC4A3--