Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80210
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.44 as permitted sender)
MIME-Version: 1.0
Reply-To: marcio3w@gmail.com
In-Reply-To: <54AB158A.9030000@gmail.com>
References: <54AB0A10.4010709@gmail.com> <D75E841E-7D75-4E7C-A234-904FFB1C15DC@ajf.me>
 <54AB0F3A.5020606@gmail.com> <06711056-CC82-41A6-BED9-FB87450C63BE@ajf.me> <54AB158A.9030000@gmail.com>
Date: Mon, 5 Jan 2015 20:14:06 -0300
Message-ID: <CAOsHV+uS1e+0gVth2gsc51Z3cADPPaseQBJo6G15uRgH=wzcgw@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Andrea Faulds <ajf@ajf.me>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1133d3760778ed050befdac1
Subject: Re: [PHP-DEV] [RFC] Parameter skipping, take 3
From: marcio.web2@gmail.com (Marcio Almada)

--001a1133d3760778ed050befdac1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Stanislav, great RFC. A huge part of core PHP API would benefit of
parameter skipping.

Andrea Faulds,

> It=E2=80=99s not that I don=E2=80=99t need this=E2=80=A6 there are some h=
orrible 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 t=
o work
around poor API design. We should get better APIs instead.

Not sure how this RFC rant is helpful since it's based on completely unreal
alternatives. This "We should get better APIs instead" suggestion, in
practice, means a ton of BC breaks that will never happen on PHP global
functions for obvious reasons.


2015-01-05 19:51 GMT-03:00 Stanislav Malyshev <smalyshev@gmail.com>:

> Hi!
>
> > Sure, but things like this make such APIs easier to work with. That=E2=
=80=99s
> > not a good thing.
>
> For me, it is. Your stance is "if it's not ideal (in my opinion) design,
> we should not do anything to make it better". I think it's wrong - there
> are many opinions about what ideal design is, and yours has no inherent
> advantage over others. Removing the existing pain is always good for me,
> and telling people "rewrite all your code or live with the pain forever"
> is not a good practical stance. It may feel very purist and satisfying -
> "here we showed these horrible people how to do things right!" - but
> practically it is next to useless. PHP has always been a practical and
> not theory-purist language, and this IMO falls directly in this category.
>
> > 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
>
> "Excessive" is a matter of opinion. If you have more than one of them,
> this RFC is helpful.
>
> > Well, some of the languages. Others have decided that named
> > parameters aren=E2=80=99t a good idea.
>
> I don't think the majority of PHP users here on your side:
>
> http://programmers.stackexchange.com/questions/27564/what-features-would-=
you-like-to-have-in-php
> Neither probably would be a majority of Python users. Or Ruby users. Of
> course, you can say all these people are horrible programmers who know
> nothing about designing APIs, but I'm afraid if you exclude all these
> from consideration when you design language features I'll get pretty
> lonely.
>
> > 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.
>
> Nobody would use "default, default, default, default" because that's
> meaningless, you could just not put them in. $foo, default, $bar would
> be much more frequent case, and that's what it is for. You can, of
> course, get it to absurd lengths, but so can be done to any feature.
>
> --
> Stas Malyshev
> smalyshev@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a1133d3760778ed050befdac1--