Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68849
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU5u+29CxpgDHs6GOoDUU+EWtm-8dr7NL4dufvSq+LZsyw@mail.gmail.com>
References: <52243BA6.5040905@sugarcrm.com> <CAEZPtU5u+29CxpgDHs6GOoDUU+EWtm-8dr7NL4dufvSq+LZsyw@mail.gmail.com>
Date: Mon, 2 Sep 2013 14:52:42 +0200
Message-ID: <CALtuQzBZ=xGK0Ra+L_1VS9tgptjbUpcU4kYESdpfOaNq5eLvcA@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e013d19f8ae68ac04e5660e6b
Subject: Re: [PHP-DEV] [RFC] Skipping parameters take 2
From: krebs.seb@gmail.com (Sebastian Krebs)

--089e013d19f8ae68ac04e5660e6b
Content-Type: text/plain; charset=ISO-8859-1

2013/9/2 Pierre Joye <pierre.php@gmail.com>

> hi Stas,
>
> On Mon, Sep 2, 2013 at 9:17 AM, Stas Malyshev <smalyshev@sugarcrm.com>
> wrote:
> > Hi!
> >
> > I've finally took some time to revive the skipping parameter RFC and
> > patch. For those who doesn't remember what it is please see:
> > https://wiki.php.net/rfc/skipparams
> > TLDR version:
> >
> > The idea is to allow skipping parameters in function with optional
> > arguments so that this:
> >    function create_query($where, $order_by, $join_type='INNER', $execute
> > = false, $report_errors = true)
> >
> > can be called like this:
> >     create_query("deleted=0", "name", default, default,
> > /*report_errors*/ true);
> >
> > Instead of trying to remember what the defaults are.
> > The patch is here:
> >
> > https://github.com/php/php-src/pull/426
> >
> > Any comments or feedback on the RFCs and the code are welcome,
> > especially pointing out the cases where it may not work (which means we
> > need more phpt's there :)
>
> Using default instead of ,,, is indeed much more readable.
>
> However I still wonder what prevents to finally implement named
> parameters too, it will provide the same feature while being even more
> handy and easier.


And it covers an additional use-case: Self-explaning parameters like in
"foo(is_strict = false)" instead of "foo(null, null, false)".


> I could dig the archives but I don't remember what
> was the reason why we rejected the idea back then.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
github.com/KingCrunch

--089e013d19f8ae68ac04e5660e6b--