Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127842
Precedence: bulk
MIME-Version: 1.0
References: <b2f466e6-b9d8-4aec-a275-e7ae7c4b67ff@app.fastmail.com> <0be8afcb6da0e8df4a9f1b446fb35bde@bastelstu.be>
In-Reply-To: <0be8afcb6da0e8df4a9f1b446fb35bde@bastelstu.be>
Date: Wed, 2 Jul 2025 18:23:22 +0200
Message-ID: <CAP1Jc12gP9z07m80OFNkCzCWbsua0Zu5sP+6ZrMw6NEpzY_U9A@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Partial Function Application v2
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: arnaud.lb@gmail.com (Arnaud Le Blanc)

Hi Tim,

We will update the RFC, but here are a few answers:

On Wednesday, July 2nd, 2025 at 17:05, Tim D=C3=BCsterhus <tim@bastelstu.be=
> wrote:
> I've now had a quick look at the implementation and the following
> questions came up that the RFC does not answer (and the tests in the PR
> do not obviously answer either):
>
> How will PFA calls appear in a stack trace and how will PFA Closures
> look like to `var_dump()`, Reflection, and to observers?

PFAs are instances of the Closure class (like FCCs), and will look
like a Closure to `var_dump()`, Reflection, and observers.

The Closure signature reflects the parameters that are accepted by the
PFA, not the underlying function (so it exposes only unbound
parameters).

    function f(int $a, int $b) {
    }

    $f =3D f(?, 2);

    echo new ReflectionFunction($f);

    // Output:
    Partial [ <user> function f ] {
      @@ test.php 5 - 5

      - Parameters [1] {
        Parameter #0 [ <required> int $a ]
      }
    }

PFA Reflection is tested in Zend/tests/partial_application/reflection_*.php=
t.

Parameter names, and which parameters are required, are defined by the
RFC. Currently, a few things are broken in the implementation,
including parameter default value reflection.

Additionally, `var_dump()` exposes bound and unbound args (with the
value of bound args). Currently the `var_dump()` output looks like
this:

    object(Closure)#1 (5) {
      ["name"]=3D>
      string(1) "f"
      ["file"]=3D>
      string(%d) "test.php"
      ["line"]=3D>
      int(7)
      ["parameter"]=3D>
      array(1) {
        ["$a"]=3D>
        string(10) "<required>"
      }
      ["args"]=3D>
      array(2) {
        ["a"]=3D>
        NULL
        ["b"]=3D>
        int(2)
      }
    }

PFAs do not appear in stack traces, only the function does.

> Classic FCC are 100% identical to the underlying function and thus can
> just =E2=80=9Cpretend=E2=80=9D they are the underlying function, but that=
 doesn't work
> for PFA. Consider the following:
>
> function foo(string $s, int $i) {
> var_dump($s, $i);
> }
>
> $f =3D foo("abc", ?);
>
> $f([]);
>
> How will the error message for the resulting TypeError look like?

Error messages refer to the underlying function as if it was called directl=
y:

    Uncaught TypeError: foo(): Argument #2 ($i) must be of type int,
array given, in test.php on line 7

The line number refers to the call site of the PFA ($f([])), not its
instantiation.

However, since PFAs must check argument count before binding them,
errors related to argument count refer to the PFA itself. Currently
the error message for $f() looks like this:

    Uncaught Error: not enough arguments for application of foo, 0
given and exactly 1 expected, declared in test.php on line 5 in
test.php on line 7

> var_dump((new ReflectionFunction($f))->getName());

The underlying function name (like FCCs)

> var_dump((new ReflectionFunction($f))->getParameters());

See above

> is_callable($f, callable_name: $name);
> var_dump($name);

Closure::__invoke (like FCCs)

> function foo(string $s, #[\SensitiveParameter] int $i) {
> throw new \Exception();
> }
>
> $f =3D foo("abc", ?);
>
> $f(123);
>
> How will the stack trace look like? Does `#[\\SensitiveParameter]` work
> properly?

This is broken, but the intent is to support attributes, so that
SensitiveParameter and other attributes work as expected.

Best Regards,
Arnaud