Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125216
Date: Sun, 25 Aug 2024 11:28:56 -0400
To: Rob Landers <rob@bottled.codes>
Cc: Matthew Weier O'Phinney <mweierophinney@gmail.com>, Bilge
 <bilge@scriptfusion.com>, PHP Developers Mailing List
 <internals@lists.php.net>
Message-ID: <5D847DC3-3BF3-4AFF-AEED-263156CA2ED9@getmailspring.com>
In-Reply-To: <ee99eb65-feba-4fac-b040-7f943801ffe6@app.fastmail.com>
References: <ee99eb65-feba-4fac-b040-7f943801ffe6@app.fastmail.com>
Subject: Re: [PHP-DEV] [RFC] Default expression
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="66cb4db8_643c9869_11f93"
From: john@coggeshall.org (John Coggeshall)

--66cb4db8_643c9869_11f93
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline



On Aug 25 2024, at 11:11 am, Rob Landers <rob=40bottled.codes> wrote:
>
> Which operants don=E2=80=99t make sense=3F
Well certainly all of the ones toward the end of the appendix in the R=46=
C the R=46C itself notes are non-sensical. Personally, I'm not sold on th=
e idea default should be an operand in an expression at all though.
I do see the value of bitwise operators / expressions as highlighted in t=
he R=46C. There might be other cases, but I'm wary of them -- I don't thi=
nk giving developers the ability to write logic and expressions against h=
ard-coded default values in upstream APIs has a lot of merit in most case=
s. I can tell you I doubt I would ever support the idea of calling method=
s of default , which I'm still unclear if this R=46C is proposing.
I would suggest a compromise where the R=46C be refocused to those expres=
sions and operators that explicitly make sense, and leave the rest of the=
m out for now. To me, that basically means =22default with bitwise expres=
sion support=22 based on what I've seen so far.
John
--66cb4db8_643c9869_11f93
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br><br><div class=3D=22gmail=5Fquote=5Fattribution=22>On Aug 25 2024, at=
 11:11 am, Rob Landers &lt;rob=40bottled.codes&gt; wrote:</div><blockquot=
e><div><br></div><div>Which operants don=E2=80=99t make sense=3F</div></b=
lockquote><br><div>Well certainly all of the ones toward the end of the a=
ppendix in the R=46C the R=46C itself notes are non-sensical. Personally,=
 I'm not sold on the idea <code>default</code>&nbsp; should be an operand=
 in an expression at all though.</div><br><div>I do see the value of bitw=
ise operators / expressions as highlighted in the R=46C. There might be o=
ther cases, but I'm wary of them -- I don't think giving developers the a=
bility to write logic and expressions against hard-coded default values i=
n upstream APIs has a lot of merit in most cases. I can tell you I doubt =
I would ever support the idea of calling methods of <code>default</code>&=
nbsp;, which I'm still unclear if this R=46C is proposing.</div><br><div>=
I would suggest a compromise where the R=46C be refocused to those expres=
sions and operators that explicitly make sense, and leave the rest of the=
m out for now. To me, that basically means =22default with bitwise expres=
sion support=22 based on what I've seen so far.</div><br><div>John</div>
--66cb4db8_643c9869_11f93--