Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125211
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 25 Aug 2024 16:08:35 +0200
To: internals@lists.php.net
Message-ID: <33d3516e-ec55-43ea-a38f-050060852389@app.fastmail.com>
In-Reply-To: <0cfd3a28-3cb0-4478-85fb-cf086d8e5c66@app.fastmail.com>
References: <0c8ed5d6-5507-4c41-8d7f-05d14ba8aa4c@scriptfusion.com>
 <0cfd3a28-3cb0-4478-85fb-cf086d8e5c66@app.fastmail.com>
Subject: Re: [PHP-DEV] [RFC] Default expression
Content-Type: multipart/alternative;
 boundary=61b7aa49b4d14ca3a8f57cc465b4bd64
From: rob@bottled.codes ("Rob Landers")

--61b7aa49b4d14ca3a8f57cc465b4bd64
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sun, Aug 25, 2024, at 15:35, Larry Garfield wrote:
> On Sat, Aug 24, 2024, at 11:49 AM, Bilge wrote:
> > Hi gang,
> >
> > New RFC just dropped: https://wiki.php.net/rfc/default_expression. I=20
> > think some of you might enjoy this one. Hit me with any feedback.
> >
> > This one already comes complete with working implementation that I'v=
e=20
> > been cooking for a little while. Considering I don't know C or PHP=20
> > internals, one might think implementing this feature would be=20
> > prohibitively difficult, but considering the amount of help and guid=
ance=20
> > I received from Ilija, Bob and others, it would be truer to say it w=
ould=20
> > have been more difficult to fail! Huge thanks to them.
> >
> > Cheers,
> > Bilge
>=20
> I am still not fully sold on this, but I like it a lot better than the=
 previous attempt at a default keyword.  It's good that you mention name=
d arguments, as those do replace like 95% of the use cases for "put defa=
ult here" in potential function calls, and the ones it doesn't, you call=
 out explicitly as the justification for this RFC.
>=20
> The approach here seems reasonable overall.  The mental model I have f=
rom the RFC is "yoink the default value out of the function, drop it int=
o this expression embedded in the function call, and let the chips fall =
where they may."  Is that about accurate?
>=20
> My main holdup is the need.  I... can't recall ever having a situation=
 where this is something I needed.  Some of the examples show valid use =
cases (eg, the "default plus this binary flag" example), but again, I've=
 never actually run into that myself in practice.

Potentially the most useful place would be in attributes. Take crell\ser=
de (:p) for instance:

#[SequenceField(implodeOn: default . ' ', joinOn: ' ' . default . ' ')]

Where you may just want it to be a little more readable, but aren't inte=
rested in the default implosion. In attributes, it has to be a static ex=
pression and I think this passes that test? At least that is one place I=
 would find most useful.

Then there are things like the example I gave before, where you need to =
call some library code as library code and pass through the intentions. =
It also gets us one step closer to something like these shenanigans:

function configureSerializer(Serde $serializer =3D new SerdeCommon(forma=
tters: default as $formatters));

Where we can call configureSerializer(formatters: new JsonStreamFormatte=
r()).

Some pretty interesting stuff.

>=20
> My other concern is the list of supported expression types.  I underst=
and how the implementation would naturally make all of those syntactical=
ly valid, but it seems many of them, if not most, are semantically nonse=
nsical.  Eg, `default > 1` would take a presumably numeric default value=
 and output a boolean, which should really never be type compatible with=
 the function being called.  (A param type of int|bool is a code smell a=
t best, and a fatal waiting to happen at worst.)  In practice, I think a=
 majority of those expressions would be logically nonsensical, so I wond=
er if it would be better to only allow a few reasonable ones and block t=
he others, to keep people from thinking nonsensical code would do someth=
ing useful.

I'm reasonably certain you can write nonsensical PHP without this featur=
e. I don't think we should be the nanny of developers.

=E2=80=94 Rob
--61b7aa49b4d14ca3a8f57cc465b4bd64
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><div>=
<br></div><div>On Sun, Aug 25, 2024, at 15:35, Larry Garfield wrote:<br>=
</div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>On Sat, Aug 24=
, 2024, at 11:49 AM, Bilge wrote:<br></div><div>&gt; Hi gang,<br></div><=
div>&gt;<br></div><div>&gt; New RFC just dropped:&nbsp;<a href=3D"https:=
//wiki.php.net/rfc/default_expression">https://wiki.php.net/rfc/default_=
expression</a>. I&nbsp;<br></div><div>&gt; think some of you might enjoy=
 this one. Hit me with any feedback.<br></div><div>&gt;<br></div><div>&g=
t; This one already comes complete with working implementation that I've=
&nbsp;<br></div><div>&gt; been cooking for a little while. Considering I=
 don't know C or PHP&nbsp;<br></div><div>&gt; internals, one might think=
 implementing this feature would be&nbsp;<br></div><div>&gt; prohibitive=
ly difficult, but considering the amount of help and guidance&nbsp;<br><=
/div><div>&gt; I received from&nbsp;Ilija, Bob and others, it would be t=
ruer to say it would&nbsp;<br></div><div>&gt; have been more difficult t=
o fail! Huge thanks to them.<br></div><div>&gt;<br></div><div>&gt; Cheer=
s,<br></div><div>&gt; Bilge<br></div><div><br></div><div>I am still not =
fully sold on this, but I like it a lot better than the previous attempt=
 at a default keyword.&nbsp; It's good that you mention named arguments,=
 as those do replace like 95% of the use cases for "put default here" in=
 potential function calls, and the ones it doesn't, you call out explici=
tly as the justification for this RFC.<br></div><div><br></div><div>The =
approach here seems reasonable overall.&nbsp; The mental model I have fr=
om the RFC is "yoink the default value out of the function, drop it into=
 this expression embedded in the function call, and let the chips fall w=
here they may."&nbsp; Is that about accurate?<br></div><div><br></div><d=
iv>My main holdup is the need.&nbsp; I... can't recall ever having a sit=
uation where this is something I needed.&nbsp; Some of the examples show=
 valid use cases (eg, the "default plus this binary flag" example), but =
again, I've never actually run into that myself in practice.<br></div></=
blockquote><div><br></div><div>Potentially the most useful place would b=
e in attributes. Take crell\serde (:p) for instance:<br></div><div><br><=
/div><div>#[SequenceField(implodeOn: default . ' ', joinOn: ' ' . defaul=
t . ' ')]<br></div><div><br></div><div>Where you may just want it to be =
a little more readable, but aren't interested in the default implosion. =
In attributes, it has to be a static expression and I think this passes =
that test? At least that is one place I would find most useful.<br></div=
><div><br></div><div>Then there are things like the example I gave befor=
e, where you need to call some library code as library code and pass thr=
ough the intentions. It also gets us one step closer to something like t=
hese shenanigans:<br></div><div><br></div><div>function configureSeriali=
zer(Serde $serializer =3D new SerdeCommon(formatters: default as $format=
ters));<br></div><div><br></div><div>Where we can call configureSerializ=
er(formatters:&nbsp;new JsonStreamFormatter()).<br></div><div><br></div>=
<div>Some pretty interesting stuff.</div><div><br></div><blockquote type=
=3D"cite" id=3D"qt" style=3D""><div><br></div><div>My other concern is t=
he list of supported expression types.&nbsp; I understand how the implem=
entation would naturally make all of those syntactically valid, but it s=
eems many of them, if not most, are semantically nonsensical.&nbsp; Eg, =
`default &gt; 1` would take a presumably numeric default value and outpu=
t a boolean, which should really never be type compatible with the funct=
ion being called.&nbsp; (A param type of int|bool is a code smell at bes=
t, and a fatal waiting to happen at worst.)&nbsp; In practice, I think a=
 majority of those expressions would be logically nonsensical, so I wond=
er if it would be better to only allow a few reasonable ones and block t=
he others, to keep people from thinking nonsensical code would do someth=
ing useful.<br></div></blockquote><div><br></div><div>I'm reasonably cer=
tain you can write nonsensical PHP without this feature. I don't think w=
e should be the nanny of developers.</div><div><br></div><div id=3D"sig1=
21229152">=E2=80=94 Rob<br></div></body></html>
--61b7aa49b4d14ca3a8f57cc465b4bd64--