Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80205
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.43 as permitted sender)
Message-ID: <54AB0F3A.5020606@gmail.com>
Date: Mon, 05 Jan 2015 14:24:58 -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>
In-Reply-To: <D75E841E-7D75-4E7C-A234-904FFB1C15DC@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!

> Yes, they complement one another. Both exist because of horrible
> APIs. But I don’t think we should encourage horrible APIs.

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.

> For well-designed functions, there is no need to skip parameters,
> either with a default keyword or with named parameters.

I disagree with that and in general I disagree with the stance "I don't
need this so the language does not need that". 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. 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. 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.

-- 
Stas Malyshev
smalyshev@gmail.com