Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125214
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 25 Aug 2024 17:11:07 +0200
To: "John Coggeshall" <john@coggeshall.org>,
 "Matthew Weier O'Phinney" <mweierophinney@gmail.com>
Cc: Bilge <bilge@scriptfusion.com>,
 "PHP Developers Mailing List" <internals@lists.php.net>
Message-ID: <ee99eb65-feba-4fac-b040-7f943801ffe6@app.fastmail.com>
In-Reply-To: <1DA8A427-85EA-449B-97AC-314958E8D49F@getmailspring.com>
References: 
 <CAJp_myW2TEVgGXLG9u1tibJpMseeqFMj8bE4+pvsnHiWHQr+Yw@mail.gmail.com>
 <1DA8A427-85EA-449B-97AC-314958E8D49F@getmailspring.com>
Subject: Re: [PHP-DEV] [RFC] Default expression
Content-Type: multipart/alternative;
 boundary=0a27b97ea03e4b29a6e6b903c26976e2
From: rob@bottled.codes ("Rob Landers")

--0a27b97ea03e4b29a6e6b903c26976e2
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sun, Aug 25, 2024, at 16:58, John Coggeshall wrote:
>=20
>=20
>> If the underlying API changes the argument type, consumers will have =
an issue regardless. For those cases where the expression is simply `def=
ault`, you'd actually be protected from the API change, which is a net b=
enefit already.=20
>>=20
>> This also protects the user from changes in the argument names.=20
>=20
> As I said, I don't have a particular problem with `default`  as a keyw=
ord to express "whatever the default value might be in the function decl=
aration", but I do have some real concerns about its use as an operand i=
n an expression. The RFC provides for a single valid use case of operato=
rs (i.e. things like `default | JSON_PRETTY_PRINT` ), yet calls for a hu=
ge array of valid operations,  many of which the RFC itself notes don't =
make much / any sense. I'd personally like to see this RFC dramatically =
reduce the scope of operations supported with `default`  as an operand i=
nitially (e.g. perhaps only bitwise ops), and revisit additional operati=
ons as needed down the road. IMO there is a very small subset of all PHP=
 operators that make any sense at all in this context, and even fewer th=
at I think are a good idea to allow even if they might make some sort of=
 sense.

Which operants don=E2=80=99t make sense?

=E2=80=94 Rob
--0a27b97ea03e4b29a6e6b903c26976e2
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 16:58, John Coggeshall wrote:<br=
></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></div><di=
v><br></div><blockquote><div><div>If the underlying API changes the argu=
ment type, consumers will have an issue regardless. For those cases wher=
e the expression is simply `default`, you'd actually be protected from t=
he API change, which is a net benefit already.&nbsp;<br></div><div><br><=
/div><div>This also protects the user from changes in the argument names=
.&nbsp;<br></div></div></blockquote><div><div><br></div><div>As I said, =
I don't have a particular problem with <code>default</code>&nbsp; as a k=
eyword to express "whatever the default value might be in the function d=
eclaration", but I do have some real concerns about its use as an operan=
d in an expression. The RFC provides for a single valid use case of oper=
ators (i.e. things like <code>default | JSON_PRETTY_PRINT</code>&nbsp;),=
 yet calls for a huge array of valid operations,&nbsp; many of which the=
 RFC itself notes don't make much / any sense. I'd personally like to se=
e this RFC dramatically reduce the scope of operations supported with <c=
ode>default</code>&nbsp; as an operand initially (e.g. perhaps only bitw=
ise ops), and revisit additional operations as needed down the road. IMO=
 there is a very small subset of all PHP operators that make any sense a=
t all in this context, and even fewer that I think are a good idea to al=
low even if they might make some sort of sense.<br></div></div></blockqu=
ote><div><br></div><div>Which operants don=E2=80=99t make sense?</div><d=
iv><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></body></ht=
ml>
--0a27b97ea03e4b29a6e6b903c26976e2--