Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125231
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------tbrs04IaKwpCG6KNhq0bi3ZW"
Message-ID: <a99e6d57-2c3a-4344-8c42-3f8fdba7ff5f@rwec.co.uk>
Date: Sun, 25 Aug 2024 19:46:54 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Default expression
To: internals@lists.php.net
References: <0c8ed5d6-5507-4c41-8d7f-05d14ba8aa4c@scriptfusion.com>
 <0cfd3a28-3cb0-4478-85fb-cf086d8e5c66@app.fastmail.com>
 <bf9b4a5b-108c-4092-8751-569c1374b054@rwec.co.uk>
 <F773FEAA-0717-43ED-A6D5-98C348298DD7@zort.net>
Content-Language: en-GB
In-Reply-To: <F773FEAA-0717-43ED-A6D5-98C348298DD7@zort.net>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------tbrs04IaKwpCG6KNhq0bi3ZW
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 25/08/2024 18:44, John Bafford wrote:

> Although I'm not sold on the idea of using default as part of an
> expression, I would argue that a default function parameter value is
> fair game to be read and manipulated by callers. If the default value
> was intended to be private, it shouldn't be in the function declaration.


There's an easy argument against this interpretation: child classes can 
freely change the default value for a parameter, as long as they do not 
make it mandatory. https://3v4l.org/SEsRm

That matches my intuition: that the public API, as a contract, states 
that the parameter is optional; the specification of what happens when 
it is not provided is an implementation detail.

For comparison, consider constructor property promotion; the caller 
shouldn't know or care whether a class is defined as:

public function __construct(private int $bar) {}

or:

private int $my_bar;
public function __construct(int $bar) { $this->my_bar = $bar; }

The syntax sits in the function signature because it's convenient, not 
because it's part of the API.


> One important case where reading the default value could be important is
>   in interoperability with different library versions. For example, a
> library might change a default parameter value between versions. If
> you're using the library, and want to support both versions, you might
> both not want to set the value, and yet also care what the default value
>   is from the standpoint of knowing what to expect out of the function.


This seems contradictory to me. If you use the default, you're telling 
the library that you don't care about that parameter, and trust it to 
provide a default.

If you want to know what the library did with its arguments, reflecting 
the signature will never be enough anyway. For example, it's quite 
common to write code like this:

function foo(?SomethingInterface $blah = null) {
     if ( $blah === null ) {
         $blah = self::_setup_default_blah();
     }
     // ...
}

A caller can't tell by looking at the signature that a new version of 
the library has changed what _setup_default_blah() returns. If the 
library doesn't provide an API to get $blah out later, then it's a 
private detail that the caller has no business inspecting.


Regards,

-- 
Rowan Tommins
[IMSoP]

--------------tbrs04IaKwpCG6KNhq0bi3ZW
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 25/08/2024 18:44, John Bafford
      wrote:</div>
    <br>
    <blockquote type="cite"
      cite="mid:F773FEAA-0717-43ED-A6D5-98C348298DD7@zort.net">
      <pre>Although I'm not sold on the idea of using default as part of an 
expression, I would argue that a default function parameter value is 
fair game to be read and manipulated by callers. If the default value 
was intended to be private, it shouldn't be in the function declaration.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>There's an easy argument against this interpretation: child
      classes can freely change the default value for a parameter, as
      long as they do not make it mandatory. <a class="moz-txt-link-freetext" href="https://3v4l.org/SEsRm">https://3v4l.org/SEsRm</a></p>
    <p>That matches my intuition: that the public API, as a contract,
      states that the parameter is optional; the specification of what
      happens when it is not provided is an implementation detail.</p>
    <p>For comparison, consider constructor property promotion; the
      caller shouldn't know or care whether a class is defined as:<br>
    </p>
    <p>public function __construct(private int $bar) {}<br>
    </p>
    <p>or:</p>
    <p>private int $my_bar;<br>
      public function __construct(int $bar) { $this-&gt;my_bar = $bar; }</p>
    <p>The syntax sits in the function signature because it's
      convenient, not because it's part of the API.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:F773FEAA-0717-43ED-A6D5-98C348298DD7@zort.net">
      <pre>One important case where reading the default value could be important is
 in interoperability with different library versions. For example, a 
library might change a default parameter value between versions. If 
you're using the library, and want to support both versions, you might 
both not want to set the value, and yet also care what the default value
 is from the standpoint of knowing what to expect out of the function.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>This seems contradictory to me. If you use the default, you're
      telling the library that you don't care about that parameter, and
      trust it to provide a default.</p>
    <p>If you want to know what the library did with its arguments,
      reflecting the signature will never be enough anyway. For example,
      it's quite common to write code like this:</p>
    <p>function foo(?SomethingInterface $blah = null) {<br>
          if ( $blah === null ) {<br>
              $blah = self::_setup_default_blah();<br>
          }<br>
          // ...<br>
      }</p>
    <p>A caller can't tell by looking at the signature that a new
      version of the library has changed what _setup_default_blah()
      returns. If the library doesn't provide an API to get $blah out
      later, then it's a private detail that the caller has no business
      inspecting.</p>
    <p><br>
    </p>
    <p>Regards,<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------tbrs04IaKwpCG6KNhq0bi3ZW--