Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80206
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.199 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <54AB0F3A.5020606@gmail.com>
Date: Mon, 5 Jan 2015 22:35:20 +0000
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <06711056-CC82-41A6-BED9-FB87450C63BE@ajf.me>
References: <54AB0A10.4010709@gmail.com> <D75E841E-7D75-4E7C-A234-904FFB1C15DC@ajf.me> <54AB0F3A.5020606@gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Parameter skipping, take 3
From: ajf@ajf.me (Andrea Faulds)

Hi Stas,

> On 5 Jan 2015, at 22:24, Stanislav Malyshev <smalyshev@gmail.com> =
wrote:
>=20
> Hi!
>=20
>> Yes, they complement one another. Both exist because of horrible
>> APIs. But I don=E2=80=99t think we should encourage horrible APIs.
>=20
> You can create horrible APIs with this, but you can also create them
> without this. This doesn't make it any more likely, it just makes
> working with optional parameters easier.

Sure, but things like this make such APIs easier to work with. That=E2=80=99=
s not a good thing.

>> For well-designed functions, there is no need to skip parameters,
>> either with a default keyword or with named parameters.
>=20
> I disagree with that and in general I disagree with the stance "I =
don't
> need this so the language does not need that=E2=80=9D.

It=E2=80=99s not that I don=E2=80=99t need this=E2=80=A6 there are some =
horrible APIs I=E2=80=99ve used which would be slightly (but only =
slightly) more pleasant to use with this feature. But I don=E2=80=99t =
think we should add features to the language to work around poor API =
design. We should get better APIs instead.

> We can and should have a
> wider look than personal needs and preferences. There are many cases
> where optional parameters have their place, and making them more
> convenient is a good thing.

There are places where optional parameters are good. I never said they =
were bad. This RFC doesn=E2=80=99t help with optional parameters, it =
helps with excessive numbers of them, or optional parameters with weird =
default values. I don=E2=80=99t think that it is necessary to have =
parameter skipping for a well-designed API. If the default values are =
obvious and intuitive, as they should be, you don=E2=80=99t need =
=E2=80=9Cdefault=E2=80=9D. If there is not an excessive number of =
parameters, you don=E2=80=99t need =E2=80=9Cdefault=E2=80=9D.

If your function takes so many arguments that you need =E2=80=9Cdefault=E2=
=80=9D, you should probably reconsider your function=E2=80=99s =
signature. If someone else=E2=80=99s function does so, you should =
probably either fix it for them or write a wrapper function, so people =
trying to read and maintain your code don=E2=80=99t gradually go insane.

> As a witness to that, most of the languages
> with this syntax model (I'm not talking about the likes of Lisp of
> course) do allow optional parameters, and making it easy to work with
> them is a very frequently requested (and implemented) feature.

Well, some of the languages. Others have decided that named parameters =
aren=E2=80=99t a good idea.

> You can,
> of course, say these all people are wrong and their code is horrible,
> but this is the reality of what people want and what they use. They'll
> do it whether you like it or not, but with this RFC it would be less
> painful. For me, it is a clear win.

I=E2=80=99m not sure if this RFC actually would make such functions that =
much less painful. For functions with a lot of default parameters, =
telling them apart is key. Seeing =E2=80=9CNULL, FALSE, FALSE, 0, =
NULL=E2=80=9D may orient the user better when scanning a parameter list =
than =E2=80=9Cdefault, default, default, default, default=E2=80=9D =
would.

Thanks!
--
Andrea Faulds
http://ajf.me/