Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105124
MIME-Version: 1.0
References: <CAHE1EdtbMsGy-TSJNvrHYcUKq=KamekJOd1+9AOV4ME2VB1j+w@mail.gmail.com>
In-Reply-To: <CAHE1EdtbMsGy-TSJNvrHYcUKq=KamekJOd1+9AOV4ME2VB1j+w@mail.gmail.com>
Date: Sat, 6 Apr 2019 18:45:38 -0400
Message-ID: <CALGLHq189gZfSu0m-5D6VbcS5_ABkWi2sKjRE5ZQpfyFScOsDw@mail.gmail.com>
To: Craig Duncan <php@duncanc.co.uk>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ee69fe0585e45e95"
Subject: Re: [PHP-DEV] Parameter skipping
From: morganbreden@gmail.com (Morgan Breden)

--000000000000ee69fe0585e45e95
Content-Type: text/plain; charset="UTF-8"

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 <php@duncanc.co.uk> wrote:

> 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 a few years ago: https://wiki.php.net/rfc/skipparams
>
> I've re-read the previous discussion and it seems to me there were two
> common arguments against:
> * Just design better APIs
> * Named parameters would be better
>
> Nobody has been able to crack named parameters (and it doesn't seem likely
> anytime soon), and as we've seen from the JSON example above it's not
> always as simple as having better APIs, so I wanted to see whether people
> would be willing to support the *default* keyword for optional parameters
> now.
>
> Thanks,
> Craig
>

--000000000000ee69fe0585e45e95--