Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125213
Date: Sun, 25 Aug 2024 10:58:14 -0400
To: Matthew Weier O'Phinney <mweierophinney@gmail.com>
Cc: Bilge <bilge@scriptfusion.com>, PHP Developers Mailing List
 <internals@lists.php.net>
Message-ID: <1DA8A427-85EA-449B-97AC-314958E8D49F@getmailspring.com>
In-Reply-To: <CAJp_myW2TEVgGXLG9u1tibJpMseeqFMj8bE4+pvsnHiWHQr+Yw@mail.gmail.com>
References: <CAJp_myW2TEVgGXLG9u1tibJpMseeqFMj8bE4+pvsnHiWHQr+Yw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Default expression
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="66cb4686_327b23c6_11f93"
From: john@coggeshall.org (John Coggeshall)

--66cb4686_327b23c6_11f93
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline



> 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.

As I said, I don't have a particular problem with default as a keyword to express "whatever the default value might be in the function declaration", but I do have some real concerns about its use as an operand in an expression. The RFC provides for a single valid use case of operators (i.e. things like default | JSON_PRETTY_PRINT ), yet calls for a huge 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 initially (e.g. perhaps only bitwise 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 at all in this context, and even fewer that I think are a good idea to allow even if they might make some sort of sense.

--66cb4686_327b23c6_11f93
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br><br><blockquote><div><div>If the underlying API changes the argument =
type, consumers will have an issue regardless. =46or those cases where th=
e expression is simply =60default=60, you'd actually be protected from th=
e API change, which is a net benefit already.&nbsp;</div><div><br></div><=
div>This also protects the user from changes in the argument names.&nbsp;=
</div></div></blockquote><div><br><div>As I said, I don't have a particul=
ar problem with <code>default</code>&nbsp; as a keyword to express =22wha=
tever the default value might be in the function declaration=22, but I do=
 have some real concerns about its use as an operand in an expression. Th=
e R=46C provides for a single valid use case of operators (i.e. things li=
ke <code>default =7C JSON=5FPRETTY=5FPRINT</code>&nbsp;), yet calls for a=
 huge array of valid operations,&nbsp; many of which the R=46C itself not=
es don't make much / any sense. I'd personally like to see this R=46C dra=
matically reduce the scope of operations supported with <code>default</co=
de>&nbsp; as an operand initially (e.g. perhaps only bitwise ops), and re=
visit additional operations as needed down the road. IMO there is a very =
small subset of all PHP operators that make any sense at all in this cont=
ext, and even fewer that I think are a good idea to allow even if they mi=
ght make some sort of sense. </div><br></div>
--66cb4686_327b23c6_11f93--