Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112883
MIME-Version: 1.0
References: <CAH=AbGL4L=uSGYVmZCXvoVsef5Qc-SH-Zmfaojuz+UTU+7S7wA@mail.gmail.com>
 <CAFrKnm=FWUuPRVERUR7hNk5Skyj6VjT+Q4fs6aT74bxwzZXRAw@mail.gmail.com>
In-Reply-To: <CAFrKnm=FWUuPRVERUR7hNk5Skyj6VjT+Q4fs6aT74bxwzZXRAw@mail.gmail.com>
Date: Thu, 14 Jan 2021 18:18:00 +0000
Message-ID: <CABVsipiL4gnfd612vAzXqZcvJMyBDKO71Ud+KunNLEpULxf=7Q@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005655cd05b8e0474e"
Subject: Re: [PHP-DEV] Feature Proposal
From: barel.barelon@gmail.com (Barel)

--0000000000005655cd05b8e0474e
Content-Type: text/plain; charset="UTF-8"

This is handled in a more elegant way by the named arguments of PHP8
https://stitcher.io/blog/php-8-named-arguments With that feature you can
just pass the parameters that you need and the others will get their
default values

Barel

On Thu, 14 Jan 2021 at 18:12, Anna Filina <afilina@gmail.com> wrote:

> > So if some calling code wants to override a later parameter, it currently
> needs to pass a value to the earlier optional parameters.
>
> I think that this is a code smell that should be addressed by a better
> design. Here's a detailed explanation of why one should use default
> parameters sparingly, along with alternatives:
> https://afilina.com/null-hell
>
> I feel like such a feature would enable developers to dig themselves
> a deeper hole towards unmaintainable code. That's just my 2 cents.
>
> Anna Filina
>
> On Thu, Jan 14, 2021 at 12:52 PM Andrew Brown <browner12@gmail.com> wrote:
>
> > This is my first foray into PHP internals, so please let me know if I'm
> > doing something wrong. Currently just following the instructions from
> > https://wiki.php.net/rfc/howto.
> >
> > Currently this proposal is only a "concept".
> >
> > I propose we add a "default" keyword that can be passed as an argument
> > into a function/method call. This would allow the calling code to defer
> to
> > the function signature for the value of a parameter.
> >
> > Traditionally, all optional parameters are placed towards the end of the
> > function parameter list, but as we all know, sometimes this order can be
> > tricky. So if some calling code wants to override a later parameter, it
> > currently needs to pass a value to the earlier optional parameters.
> >
> > A current solution around this is to define all defaults in the body of
> > the function rather than in the signature.
> >
> > [image: Screen-Shot-2021-01-14-at-11.45.09-AM.jpg]
> >
> > However, this adds some extra boilerplate, and we can't use default
> > parameters as they were really intended.
> >
> > My proposal is to add a new `default` keyword to be passed as an
> argument.
> >
> > [image: Screen-Shot-2021-01-14-at-11.44.57-AM.jpg]
> >
> > The first call of the function here is how we currently have to do
> things.
> > We have to explicitly pass `true` in as the second parameter.
> >
> > However, in the second call, we now use the new `default` keyword, which
> > will defer to the function signature for the default value of `$param2`.
> >
> > Thanks all, looking forward to some feedback!
> >
> > --
> > Andrew M. Brown
> >
>

--0000000000005655cd05b8e0474e--