On 07/04/2019 11:53, Morgan Breden wrote:
>In order to use named parameters, somebody needs to have declared
what those names are, and made them a stable API. If they're
automatically supported on existing functions, the author might not
intend them to be used, or even realise they can, so not
>In order to use named parameters, somebody needs to have declared what
those names are, and made them a stable API. If they're automatically
supported on existing functions, the author might not intend them to be
used, or even realise they can, so not keep them stable (I tend to think of
parameter
On 7 April 2019 06:00:53 BST, CHU Zhaowei wrote:
>The [named parameters](https://wiki.php.net/rfc/named_params) was
>proposed in 2013. Does the problems which stopped us before still exist
>in 2019? Since we all agree named parameter should be a better
>solution, why not take a look at it first?
I mean it’s easier than named parameters. I guess I replied to wrong thread,
but wanted to contrast “default” with JSON_DEFAULT_DEPTH. Accepting string in
integer parameter just creates mores issues. And please don’t use name
conflicts as argument for not adding something. It’s absurd to stop ad
> > The problem I see with this approach is that a keyword for skipping
> > parameters would really just be a stopgap solution until something
> > like Named Parameters can be added.
> >
> > Is it really appropriate to add a feature that only serves a temporary
> > purpose?
>
> That was an argu
Hi!
> The problem I see with this approach is that a keyword for skipping
> parameters
> would really just be a stopgap solution until something like Named
> Parameters
> can be added.
>
> Is it really appropriate to add a feature that only serves a temporary
> purpose?
That was an argument in 2
Why not just wrap the function in another function?
On Sat, 6 Apr 2019 at 23:46, Morgan Breden wrote:
>
> The problem I see with this approach is that a keyword for skipping
> parameters
> would really just be a stopgap solution until something like Named
> Parameters
> can be added.
>
> Is it re
The problem I see with this approach is that a keyword for skipping
parameters
would really just be a stopgap solution until something like Named
Parameters
can be added.
Is it really appropriate to add a feature that only serves a temporary
purpose?
On Sat, Apr 6, 2019 at 5:15 PM Craig Duncan w
Hi all,
After starting to use https://wiki.php.net/rfc/json_throw_on_error in PHP
7.3 I've encountered the annoying issue of having to pass the $depth
parameter as 512 every time I want json_decode() to throw.
After doing this a few times I remembered the parameter skipping RFC that
Stas proposed
