Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125293
Precedence: bulk
MIME-Version: 1.0
References: <CAJp_myV3Riup2DyDWjgpHypDE6qP03Ogzdr6mZo6wWUmCtx16g@mail.gmail.com>
 <E1458589-B95C-43D0-A654-F8DB75782AB7@getmailspring.com>
In-Reply-To: <E1458589-B95C-43D0-A654-F8DB75782AB7@getmailspring.com>
Date: Mon, 26 Aug 2024 16:27:55 -0500
Message-ID: <CAJp_myXPpgmxkJautxUiADLz_fgVNv4RJSkpz_duAao9acSojA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Default expression
To: John Coggeshall <john@coggeshall.org>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000008cedb06209ccd1d"
From: mweierophinney@gmail.com ("Matthew Weier O'Phinney")

--00000000000008cedb06209ccd1d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 26, 2024 at 3:45=E2=80=AFPM John Coggeshall <john@coggeshall.or=
g> wrote:

>
>
> On Aug 26 2024, at 2:11 pm, Matthew Weier O'Phinney <
> mweierophinney@gmail.com> wrote:
>
>
> I can see a few others:
>
> - string concatenation. I might want to prepend or append a string to a
> default.
>
> - fractional or multiplicative application, e.g. for durations/timeouts.
> These might require testing for non-zero first as well.
>
>
> I have to be honest all of these both sound like really bad practices.
> Maybe I'm just not being imaginative enough... but if you don't control t=
he
> upstream library why would you ever trust it like that? Writing a timeout=
 default
> * 0.5  when default  is 1000  is a really bad way to set your timeout to
> 500  -- because next time you done a composer update  suddenly the
> upstream package set the timeout to 5000  and now instead of 500 your
> timeout has silently become 2500.
>

You'll likely identify the increased delay in such cases. Generally
speaking these sorts of default values don't change a ton, but it's not
unlikely that you may say "I'd like half that delay" or "twice that delay".
But a better example would be introducing a backoff, which might look like
this:

    for ($i =3D 1; $i +=3D 1 ; $i < 4) {
        $result =3D call_some_client($url, default * $i);
        if ($result->isSuccess()) {
            break;
        }
    }

In other words, you know that you want it to use the default, and then
allow an increasing timeout duration between calls if it fails. For this, I
don't necessarily want or need to know what the default is, only that I
want to do _multiples_ of it in specific cases.

Is it a universally good idea? No. Does it have use cases? Yes.

- decorating a default instance (e.g. to lazily create a proxy without
> knowing the default implementation used for an argument hinted against an
> interface)
>
>
> This is exactly the usage I'm highlighted as problematic in my code
> example. You're introducing a new worry for the upstream API developer th=
at
> doesn't need to exist, and violating a separation principle that has
> existed in PHP since default parameters were created 25+ years ago.
>

How exactly is this worrisome? Consider this:

    class A {
        public function __construct(private LogInterface $logger =3D new
DefaultLogger()) { }
    }

    class ProxiedLogger implements LogInterface { ... }

    $a =3D new A(new ProxyLogger(default));

If class A is programming to the `LogInterface` contract, the fact that it
gets a proxied version of the default should not matter in the least. Being
able to proxy like this means that a _consumer_ of class A does not need to
know or care what the default implementation is; they can assume it follows
the same contract, and proxy to it regardless. The upstream developer
doesn't need to care, because they are programming to the interface, not
the implementation. This doesn't violate the separation of concerns
principle, nor covariance.


> IF it's possible to accomplish, I think it's better to identify the
> "leaving this open will create WTF situations" than to prematurely lock
> _everything_ down up front.
>
>
> If this feature is released with an overly broad scope in terms of
> expressions, etc. it's not like we can take it back at that point because
> now people are using it in unknown ways. It is not one I'm comfortable wi=
th
> a "let's move forward and see what happens" approach.
>

I didn't say that at all. I said we should identify the ones we absolutely
know will be problematic, and restrict those from the outset. From there,
we should identify the ones that _might_ be problematic, and determine on a
case by case basis if the risks outweigh the use cases before Bilge brings
it to a vote.

But if we lock it down too tightly from the outset, expanding it, while
being possible, will more than likely mean an RFC for every expansion,
because it's unlikely somebody will do anything comprehensive towards
opening it up in the future. I'd rather not leave some of these use cases
as a TBD for a later RFC, because that's very likely going to mean "never".

I DO think there are likely whole categories of expressions we can likely
say "no" to - anything where the default represents a union type (and
_mixed_ is a union type) should likely only allow default by itself or as a
bare value on the RHS of an expression.

The argument against the feature that it expands the public API is puzzling
to me, particularly when the only other solutions are (a) Reflection, or
(b) named arguments. Named arguments _are_ part of the public API, as the
names themselves can change. Default values can change, but, importantly, a
change in a default value does not change the actual signature of a
function. Giving the ability to use `default` gives consumers of a function
a far more stable API surface, particularly when they do not want to change
a given default value, but _do_ want to provide a more specific value for a
later argument. Right now, if not using named arguments (e.g., because
you're worried the argument name could change), your only other option is
to use the Reflection API, which is more expensive, introduces a whole set
of other possible runtime issues, and is far more convoluted to achieve.

Without this RFC, those are your only options.

Had this been only to allow the `default` keyword, I don't think we'd be
having this discussion at all; I think it would be pretty self-evident that
there's a need, and a lot of folks would be happy to sign on.

But the author took it a step further, and asked, "What if ...?", and as
such, the RFC provides additional benefits beyond giving you a keyword for
using the default value, as it expands to allowing expressions. This gives
a tremendous amount of flexibility and power, and solves some additional
issues some of us have noticed.

So I'd argue that what we need to weigh now is which of these expressions
are truly benefits, which ones are side effects we can live with, and which
will raise new problems we do not want to deal with.

Again, there are a few lists going around on this thread, and I hope that
Bilge is taking notes to add to the RFC, and working with the folks who
helped him with implementation to determine what is and is not possible in
terms of the grammar so we can potentially exclude the more problematic
ones.

But let's not just say "no expressions" - I think there's been some
demonstrated value from a lot of these.

>
>

--=20
Matthew Weier O'Phinney
mweierophinney@gmail.com
https://mwop.net/
he/him

--00000000000008cedb06209ccd1d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, Aug 26, 2024 at 3:45=E2=80=AF=
PM John Coggeshall &lt;<a href=3D"mailto:john@coggeshall.org">john@coggesha=
ll.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><br><br><div>On Aug 26 2024, at 2:11 pm, Matthew Weier O&#39;Phinney =
&lt;<a href=3D"mailto:mweierophinney@gmail.com" target=3D"_blank">mweieroph=
inney@gmail.com</a>&gt; wrote:</div><blockquote><div><div><br></div><div>I =
can see a few others:</div><div><br></div><div>- string concatenation. I mi=
ght want to prepend or append a string to a default.=C2=A0</div><div><br></=
div><div>- fractional or multiplicative application, e.g. for durations/tim=
eouts. These might require testing for non-zero first as well.</div></div><=
/blockquote><div><br><div>I have to be honest all of these both sound like =
really bad practices. Maybe I&#39;m just not being imaginative enough... bu=
t if you don&#39;t control the upstream library why would you ever trust it=
 like that? Writing a timeout <code>default * 0.5</code>=C2=A0 when <code>d=
efault</code>=C2=A0 is <code>1000 </code>=C2=A0is a really bad way to set y=
our timeout to <code>500</code>=C2=A0 -- because next time you done a <code=
>composer update</code>=C2=A0 suddenly the upstream package set the timeout=
 to <code>5000</code>=C2=A0 and now instead of 500 your timeout has silentl=
y become <code>2500.</code></div></div></blockquote><div><br></div><div>You=
&#39;ll likely identify the increased delay in such cases. Generally speaki=
ng these sorts of default values don&#39;t change a ton, but it&#39;s not u=
nlikely that you may say &quot;I&#39;d like half that delay&quot; or &quot;=
twice that delay&quot;. But a better example would be introducing a backoff=
, which might look like this:<br></div><div><br></div><div>=C2=A0 =C2=A0 fo=
r ($i =3D 1; $i=C2=A0+=3D 1 ; $i &lt; 4) {</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 $result =3D call_some_client($url, default * $i);</div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 if ($result-&gt;isSuccess()) {</div><div>=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }=
</div><div>=C2=A0 =C2=A0 }</div><div><br></div><div>In other words, you kno=
w that you want it to use the default, and then allow an increasing timeout=
 duration between calls if it fails. For this, I don&#39;t necessarily want=
 or need to know what the default is, only that I want to do _multiples_ of=
 it in specific cases.</div><div><br></div><div>Is it a universally good id=
ea? No. Does it have use cases? Yes.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div><blockquote>- decorating a default in=
stance (e.g. to lazily create a proxy without knowing the default implement=
ation used for an argument hinted against an interface)</blockquote><br><di=
v>This is exactly the usage I&#39;m highlighted as problematic in my code e=
xample. You&#39;re introducing a new worry for the upstream API developer t=
hat doesn&#39;t need to exist, and violating a separation principle that ha=
s existed in PHP since default parameters were created 25+ years ago.</div>=
</div></blockquote><div><br></div><div>How exactly is this worrisome? Consi=
der this:</div><div><br></div><div>=C2=A0 =C2=A0 class A {</div><div>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 public function __construct(private LogInterface $log=
ger =3D new DefaultLogger()) { }</div><div>=C2=A0 =C2=A0 }</div><div><br></=
div><div>=C2=A0 =C2=A0 class ProxiedLogger implements LogInterface { ... }<=
/div><div><br></div><div>=C2=A0 =C2=A0 $a =3D new A(new ProxyLogger(default=
));</div><div><br></div><div>If class A is programming to the `LogInterface=
` contract, the fact that it gets a proxied version of the default should n=
ot matter in the least. Being able to proxy like this means that a _consume=
r_ of class A does not need to know or care what the default implementation=
 is; they can assume it follows the same contract, and proxy to it regardle=
ss. The upstream developer doesn&#39;t need to care, because they are progr=
amming to the interface, not the implementation. This doesn&#39;t violate t=
he separation of concerns principle, nor covariance.</div><div>=C2=A0 =C2=
=A0=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><bloc=
kquote>IF it&#39;s possible to accomplish, I think it&#39;s better to ident=
ify the &quot;leaving this open will create WTF situations&quot; than to pr=
ematurely lock _everything_ down up front.=C2=A0</blockquote><div><br><div>=
If this feature is released with an overly broad scope in terms of expressi=
ons, etc. it&#39;s not like we can take it back at that point because now p=
eople are using it in unknown ways. It is not one I&#39;m comfortable with =
a &quot;let&#39;s move forward and see what happens&quot; approach.</div></=
div></div></blockquote><div><br></div><div>I didn&#39;t say that at all. I =
said we should identify the ones we absolutely know will be problematic, an=
d restrict those from the outset. From there, we should identify the ones t=
hat _might_ be problematic, and determine on a case by case basis if the ri=
sks outweigh the use cases before Bilge brings it to a vote.</div><div><br>=
</div><div>But if we lock it down too tightly from the outset, expanding it=
, while being possible, will more than likely mean an RFC for every expansi=
on, because it&#39;s unlikely somebody will do anything comprehensive towar=
ds opening it up in the future. I&#39;d rather not leave some of these use =
cases as a TBD for a later RFC, because that&#39;s very likely going to mea=
n &quot;never&quot;.</div><div><br></div><div>I DO think there are likely w=
hole categories of expressions we can likely say &quot;no&quot; to - anythi=
ng where the default represents a union type (and _mixed_ is a union type) =
should likely only allow default by itself or as a bare value on the RHS of=
 an expression.</div><div><br></div><div>The argument against the feature t=
hat it expands the public API is puzzling to me, particularly when the only=
 other solutions are (a) Reflection, or (b) named arguments. Named argument=
s _are_ part of the public API, as the names themselves can change. Default=
 values can change, but, importantly, a change in a default value does not =
change the actual signature of a function. Giving the ability to use `defau=
lt` gives consumers of a function a far more stable API surface, particular=
ly when they do not want to change a given default value, but _do_ want to =
provide a more specific value for a later argument. Right now, if not using=
 named arguments (e.g., because you&#39;re worried the argument name could =
change), your only other option is to use the Reflection API, which is more=
 expensive, introduces a whole set of other possible runtime issues, and is=
 far more convoluted to achieve.<br></div><div><br></div><div>Without this =
RFC, those are your only options.</div><div><br></div><div>Had this been on=
ly to allow the `default` keyword, I don&#39;t think we&#39;d be having thi=
s discussion at all; I think it would be pretty self-evident that there&#39=
;s a need, and a lot of folks would be happy to sign on.</div><div><br></di=
v><div>But the author took it a step further, and asked, &quot;What if ...?=
&quot;, and as such, the RFC provides additional benefits beyond giving you=
 a keyword for using the default value, as it expands to allowing expressio=
ns. This gives a tremendous amount of flexibility and power, and solves som=
e additional issues some of us have noticed.</div><div><br></div><div>So I&=
#39;d argue that what we need to weigh now is which of these expressions ar=
e truly benefits, which ones are side effects we can live with, and which w=
ill raise new problems we do not want to deal with.</div><div><br></div><di=
v>Again, there are a few lists going around on this thread, and I hope that=
 Bilge is taking notes to add to the RFC, and working with the folks who he=
lped him with implementation to determine what is and is not possible in te=
rms of the grammar so we can potentially exclude the more problematic ones.=
</div><div><br></div><div>But let&#39;s not just say &quot;no expressions&q=
uot; - I think there&#39;s been some demonstrated value from a lot of these=
.</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br></di=
v></div></blockquote></div><br clear=3D"all"><div><br></div><span class=3D"=
gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signa=
ture"><div dir=3D"ltr"><div>Matthew Weier O&#39;Phinney<br><a href=3D"mailt=
o:mweierophinney@gmail.com" target=3D"_blank">mweierophinney@gmail.com</a><=
br><a href=3D"https://mwop.net/" target=3D"_blank">https://mwop.net/</a></d=
iv><div>he/him<br></div></div></div></div>

--00000000000008cedb06209ccd1d--