Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127890
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 05 Jul 2025 00:27:34 +0200
To: internals@lists.php.net
Message-ID: <6a9d4f24-65e4-40ee-bf16-9b1120486d83@app.fastmail.com>
In-Reply-To: <b2f466e6-b9d8-4aec-a275-e7ae7c4b67ff@app.fastmail.com>
References: <b2f466e6-b9d8-4aec-a275-e7ae7c4b67ff@app.fastmail.com>
Subject: Re: [PHP-DEV] [RFC] Partial Function Application v2
Content-Type: multipart/alternative;
 boundary=a053ecee004a4c46bd4c7092edcc4f68
From: rob@bottled.codes ("Rob Landers")

--a053ecee004a4c46bd4c7092edcc4f68
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sat, Jun 28, 2025, at 07:06, Larry Garfield wrote:
> Hi folks.  Arnaud and I would like to present take-2 at Partial Functi=
on Application.
>=20
> https://wiki.php.net/rfc/partial_function_application_v2
>=20
> It is largely similar to the previous PFA proposal from 2021, though t=
here are a number of changes.  Most notably:
>=20
> * The implementation is simpler, because FCC already did part of the w=
ork.  This RFC can build on it.
> * Constructors are not supported.
> * But optional arguments and named placeholders are supported.
> * It includes pipe-based optimizations.
>=20
> Note: We realize that this is a non-trivial RFC coming late in the cyc=
le.  We are proposing it now because, well, it's ready now.  If the disc=
ussion goes smoothly, we're OK calling a vote on it for 8.5, especially =
as it would complement pipes so well.  If the discussion runs longer, we=
're also OK with targeting 8.6 instead.  We'll see how that goes.
>=20
> <floor opens for discussion, Larry falls through the trap door>
>=20
> --=20
>   Larry Garfield
>   larry@garfieldtech.com
>=20

Hi Larry,

I hope your trip through the trap door is largely uneventful with a smoo=
th integration into 8.5.

My only question: why does this implementation care if you specify too m=
any arguments when PHP doesn=E2=80=99t care if you call a function with =
too many arguments?

I think it=E2=80=99s a good thing that it cares, and I think PHP itself =
should care, but should this RFC change that expectation?

=E2=80=94 Rob
--a053ecee004a4c46bd4c7092edcc4f68
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Sat, Jun 28, 2025, at 07:06, Larry Garfield wrote:<=
/div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Hi folks.&nbsp;=
 Arnaud and I would like to present take-2 at Partial Function Applicati=
on.</div><div><br></div><div><a href=3D"https://wiki.php.net/rfc/partial=
_function_application_v2">https://wiki.php.net/rfc/partial_function_appl=
ication_v2</a></div><div><br></div><div>It is largely similar to the pre=
vious PFA proposal from 2021, though there are a number of changes.&nbsp=
; Most notably:</div><div><br></div><div>* The implementation is simpler=
, because FCC already did part of the work.&nbsp; This RFC can build on =
it.</div><div>* Constructors are not supported.</div><div>* But optional=
 arguments and named placeholders are supported.</div><div>* It includes=
 pipe-based optimizations.</div><div><br></div><div>Note: We realize tha=
t this is a non-trivial RFC coming late in the cycle.&nbsp; We are propo=
sing it now because, well, it's ready now.&nbsp; If the discussion goes =
smoothly, we're OK calling a vote on it for 8.5, especially as it would =
complement pipes so well.&nbsp; If the discussion runs longer, we're als=
o OK with targeting 8.6 instead.&nbsp; We'll see how that goes.</div><di=
v><br></div><div>&lt;floor opens for discussion, Larry falls through the=
 trap door&gt;</div><div><br></div><div>--&nbsp;</div><div>&nbsp; Larry =
Garfield</div><div>&nbsp;&nbsp;<a href=3D"mailto:larry@garfieldtech.com"=
>larry@garfieldtech.com</a></div><div><br></div></blockquote><div><br></=
div><div>Hi Larry,</div><div><br></div><div>I hope your trip through the=
 trap door is largely uneventful with a smooth integration into 8.5.</di=
v><div><br></div><div>My only question: why does this implementation car=
e if you specify too many arguments when PHP doesn=E2=80=99t care if you=
 call a function with too many arguments?</div><div><br></div><div>I thi=
nk it=E2=80=99s a good thing that it cares, and I think PHP itself shoul=
d care, but should this RFC change that expectation?</div><div><br></div=
><div id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--a053ecee004a4c46bd4c7092edcc4f68--