Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80207
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.174 as permitted sender)
Message-ID: <54AB158A.9030000@gmail.com>
Date: Mon, 05 Jan 2015 14:51:54 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Andrea Faulds <ajf@ajf.me>
CC: PHP Internals <internals@lists.php.net>
References: <54AB0A10.4010709@gmail.com> <D75E841E-7D75-4E7C-A234-904FFB1C15DC@ajf.me> <54AB0F3A.5020606@gmail.com> <06711056-CC82-41A6-BED9-FB87450C63BE@ajf.me>
In-Reply-To: <06711056-CC82-41A6-BED9-FB87450C63BE@ajf.me>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Parameter skipping, take 3
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> Sure, but things like this make such APIs easier to work with. That’s
> 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’t 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’t 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 “NULL, FALSE, FALSE, 0, NULL” may orient
> the user better when scanning a parameter list than “default,
> default, default, default, default” 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