Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125267
Precedence: bulk
MIME-Version: 1.0
References: <0c8ed5d6-5507-4c41-8d7f-05d14ba8aa4c@scriptfusion.com>
 <0cfd3a28-3cb0-4478-85fb-cf086d8e5c66@app.fastmail.com> <3e0d031e-256f-47cd-9a2b-dcdc760f5498@scriptfusion.com>
 <e2cd7203-8a25-494d-9c9d-b8abad02c8e8@rwec.co.uk> <6afeb23a-867f-457d-9b13-fdf5af02c31e@scriptfusion.com>
 <F374AE89-A6E4-4C40-9C33-6569D47589ED@rwec.co.uk> <928d6c8c-c969-4d55-82ff-5da8fc3d3035@scriptfusion.com>
 <73301950-03e7-4f3c-9fab-402645f77272@gmx.de> <e2b64837-2a28-4968-bce3-bbc06165d2bd@scriptfusion.com>
 <bcfa8d1f-8a2f-4c39-bf5d-a85f0ba4e20e@app.fastmail.com>
In-Reply-To: <bcfa8d1f-8a2f-4c39-bf5d-a85f0ba4e20e@app.fastmail.com>
Date: Mon, 26 Aug 2024 13:36:28 +0200
Message-ID: <CAJmjfvXkZsWUK3aGY+EM+3T52ezbdttJ2FSCoxh9t=wyHZCgMw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Default expression
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000cf021a0620948913"
From: jakob@givoni.dk (Jakob Givoni)

--000000000000cf021a0620948913
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 26, 2024 at 12:49=E2=80=AFPM Rowan Tommins [IMSoP] <imsop.php@r=
wec.co.uk>
wrote:

> On Mon, 26 Aug 2024, at 10:14, Bilge wrote:
> > You're absolutely right, I would be interested to see any viable patch
> > that effectively implements a set of restrictions on how `default` may
> > be used. Requesting it be done at the parser level was not meant as a
> > gotcha, that's just how I (with my lack of experience) would have
> > approached it, but certainly trapping cases in the compiler is equally,
> > if not more valid and/or practical.
>
> Another approach that occurred to me was in the executor: rather than
> evaluating to the default value immediately, "default" could resolve to a
> special value, essentially wrapping the reflection parameter info. Then
> when the function is actually called, it would be "unboxed" and the actua=
l
> value fetched, but use in any other context would be a type error.
>
> That would allow arbitrarily complex expressions to resolve to "default",
> but not perform any operations on it - a bit like propagating sqrt(-1)
> through an engineering formula where you know it will be cancelled out
> eventually.
>
>
I 100% agree with this.
"default" should not evaluate to a value before sending it as an argument
to the function or method.
I understand from what the RFC author wrote a while ago that doing so
(evaluating to the actual default value using reflection) was the easier
and perhaps only viable way at the moment, but if that's the case, I don't
think the value of this RFC justifies doing something like that, which to
me seems like a hack.

For those already expressing interest in being able to modify a binary flag
default parameter using this "trick", I still don't think it justifies this
RFC. In my opinion, functions that accept multiple arbitrary options by
compressing them into a binary flag have a badly designed interface to
begin with.

So, my 10c: Make "default" a pure keyword / immutable value if possible, or
reconsider whether this feature is really worth the fuss.

Best,
Jakob

--000000000000cf021a0620948913
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 12:49=E2=80=
=AFPM Rowan Tommins [IMSoP] &lt;<a href=3D"mailto:imsop.php@rwec.co.uk">ims=
op.php@rwec.co.uk</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">On Mon, 26 Aug 2024, at 10:14, Bilge wrote:<br>
&gt; You&#39;re absolutely right, I would be interested to see any viable p=
atch <br>
&gt; that effectively implements a set of restrictions on how `default` may=
 <br>
&gt; be used. Requesting it be done at the parser level was not meant as a =
<br>
&gt; gotcha, that&#39;s just how I (with my lack of experience) would have =
<br>
&gt; approached it, but certainly trapping cases in the compiler is equally=
, <br>
&gt; if not more valid and/or practical.<br>
<br>
Another approach that occurred to me was in the executor: rather than evalu=
ating to the default value immediately, &quot;default&quot; could resolve t=
o a special value, essentially wrapping the reflection parameter info. Then=
 when the function is actually called, it would be &quot;unboxed&quot; and =
the actual value fetched, but use in any other context would be a type erro=
r.<br>
<br>
That would allow arbitrarily complex expressions to resolve to &quot;defaul=
t&quot;, but not perform any operations on it - a bit like propagating sqrt=
(-1) through an engineering formula where you know it will be cancelled out=
 eventually.<br><br></blockquote><div><br></div><div>I 100% agree with this=
.</div><div>&quot;default&quot; should not evaluate to a value before sendi=
ng it as an argument to the function or method.</div><div>I understand from=
 what the RFC author wrote a while ago that doing so (evaluating to the act=
ual default value using reflection) was the easier and perhaps only viable =
way at the moment, but if that&#39;s the case, I don&#39;t think the value =
of this RFC justifies doing something like that, which to me seems like a h=
ack.</div><div><br></div><div>For those already expressing interest in bein=
g able to modify a binary flag default parameter using this &quot;trick&quo=
t;, I still don&#39;t think it justifies this RFC. In my opinion, functions=
 that accept=C2=A0multiple arbitrary options by compressing them into a bin=
ary flag have a badly designed interface to begin with.</div><div><br></div=
><div>So, my 10c: Make &quot;default&quot; a pure keyword / immutable value=
 if possible, or reconsider whether this feature is really worth the fuss.<=
/div><div><br></div><div>Best,</div><div>Jakob</div><div><br></div><div>=C2=
=A0</div></div></div>

--000000000000cf021a0620948913--