Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125212
Precedence: bulk
MIME-Version: 1.0
References: <0c8ed5d6-5507-4c41-8d7f-05d14ba8aa4c@scriptfusion.com> <E7303985-17AE-461E-94F1-A14B24DC07A7@getmailspring.com>
In-Reply-To: <E7303985-17AE-461E-94F1-A14B24DC07A7@getmailspring.com>
Date: Sun, 25 Aug 2024 09:33:12 -0500
Message-ID: <CAJp_myW2TEVgGXLG9u1tibJpMseeqFMj8bE4+pvsnHiWHQr+Yw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Default expression
To: John Coggeshall <john@coggeshall.org>
Cc: Bilge <bilge@scriptfusion.com>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000eb942e062082e36d"
From: mweierophinney@gmail.com ("Matthew Weier O'Phinney")

--000000000000eb942e062082e36d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Aug 25, 2024, 9:06=E2=80=AFAM John Coggeshall <john@coggeshall.org>=
 wrote:

>
>
> On Aug 24 2024, at 12:49 pm, Bilge <bilge@scriptfusion.com> wrote:
>
> Hi gang,
>
> New RFC just dropped: https://wiki.php.net/rfc/default_expression. I
> think some of you might enjoy this one. Hit me with any feedback.
>
>
> Seems like you are missing an option for your theme example, which would
> be to simply extend the Config  class?
>
> While I can see the value in the concept of default , I think it's a
> mistake to allow default  to be used as a generic operand as shown in the
> RFC appendix. It seems to me that the whole point of something like
> default  is to not have to worry about what the upstream API wanted for
> that value, but the second you start allowing operations where default
> is an operand you've reintroduced the problem you were trying to avoid if
> the upstream API were to change the type of what default  ultimately
> resolves to. Worse actually because now I have no idea what default  is
> when I read code without having to dig up the upstream API.
>

If the underlying API changes the argument type, consumers will have an
issue regardless. For those cases where the expression is simply `default`,
you'd actually be protected from the API change, which is a net benefit
already.

This also protects the user from changes in the argument names.


> Other thoughts here are what happens when default  resolves to an object
> or enumeration or something complex? Your original example had CuteTheme =
,
> so can you call a method of default ?? I could entirely see someone doing
> something like this for example:
>
> enum Foo:string {
>     // cases
>
>     public function buildSomeValidBasedOnCase(): int { // ... }
> }
>
> F(MyClass::makeBasedOnValue(default->buildSomeValidBasedOnCase()))
>
> IMO most operators listed in the appendix should be disallowed. I can see
> the value of default | JSON_PRETTY_PRINT,  but I am pretty strongly
> opposed to the idea of introducing a "conditional based on the default
> value of an upstream API call" concept of default >=3D1 .
>
>
>

--000000000000eb942e062082e36d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Sun, Aug 25, 2024, 9:06=E2=80=AFAM John Coggeshall =
&lt;<a href=3D"mailto:john@coggeshall.org">john@coggeshall.org</a>&gt; wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><br><br><div>On Aug 24 2024, at =
12:49 pm, Bilge &lt;<a href=3D"mailto:bilge@scriptfusion.com" target=3D"_bl=
ank" rel=3D"noreferrer">bilge@scriptfusion.com</a>&gt; wrote:</div><blockqu=
ote><div><div>Hi gang,</div><br><div>New RFC just dropped: <a href=3D"https=
://wiki.php.net/rfc/default_expression" target=3D"_blank" rel=3D"noreferrer=
">https://wiki.php.net/rfc/default_expression</a>. I</div><div>think some o=
f you might enjoy this one. Hit me with any feedback.</div><br></div></bloc=
kquote><div><br><div>Seems like you are missing an option for your theme ex=
ample, which would be to simply extend the <code>Config</code>=C2=A0 class?=
</div><br><div>While I can see the value in the concept of <code>default</c=
ode>=C2=A0, I think it&#39;s a mistake to allow <code>default</code>=C2=A0 =
to be used as a generic operand as shown in the RFC appendix. It seems to m=
e that the whole point of something like <code>default</code>=C2=A0 is to n=
ot have to worry about what the upstream API wanted for that value, but the=
 second you start allowing operations where <code>default</code>=C2=A0 is a=
n operand you&#39;ve reintroduced the problem you were trying to avoid if t=
he upstream API were to change the type of what <code>default</code>=C2=A0 =
ultimately resolves to. Worse actually because now I have no idea what <cod=
e>default</code>=C2=A0 is when I read code without having to dig up the ups=
tream API.</div></div></blockquote></div></div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">If the underlying API changes the argument type, consumer=
s will have an issue regardless. For those cases where the expression is si=
mply `default`, you&#39;d actually be protected from the API change, which =
is a net benefit already.=C2=A0</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">This also protects the user from changes in the argument names.=
=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div><br><div>Other thoughts here =
are what happens when <code>default</code>=C2=A0 resolves to an object or e=
numeration or something complex? Your original example had <code>CuteTheme<=
/code>=C2=A0, so can you call a method of <code>default</code>=C2=A0?? I co=
uld entirely see someone doing something like this for example:</div><br><d=
iv>enum Foo<span>:string</span>=C2=A0{</div><div>=C2=A0=C2=A0=C2=A0 // case=
s</div><br><div>=C2=A0=C2=A0=C2=A0 public function buildSomeValidBasedOnCas=
e(): int { // ... }</div><div>}</div><br><div>F(MyClass:<span>:makeBasedO</=
span>nValue(default-&gt;buildSomeValidBasedOnCase()))</div><br><div>IMO mos=
t operators listed in the appendix should be disallowed. I can see the valu=
e of <code>default | JSON_PRETTY_PRINT,</code>=C2=A0 but I am pretty strong=
ly opposed to the idea of introducing a &quot;conditional based on the defa=
ult value of an upstream API call&quot; concept of <code>default &gt;=3D1</=
code>=C2=A0.</div><br><br></div></blockquote></div></div></div>

--000000000000eb942e062082e36d--