Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60174
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mohiva.com from 80.67.31.39 cause and error)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 18 Apr 2012 11:16:18 +0200
To: <internals@lists.php.net>
In-Reply-To: <CAH-PCH5PZF=Yj7=Wq2WzoG9xsUgzW0axrmBTF1yvKyxviefdGw@mail.gmail.com>
References: <4F8DF4B1.2040307@sugarcrm.com>
 <CAH-PCH5PZF=Yj7=Wq2WzoG9xsUgzW0axrmBTF1yvKyxviefdGw@mail.gmail.com>
Message-ID: <033efe40c5a08f856d79ee32cd9f2922@mohiva.com>
User-Agent: Roundcube Webmail/0.6
Subject: Re: [PHP-DEV] [RFC] skipping optional parameters
From: christian.kaps@mohiva.com (Christian Kaps)

Am 18.04.2012 09:18, schrieb Ferenc Kovacs:
> On Wed, Apr 18, 2012 at 12:54 AM, Stas Malyshev
> <smalyshev@sugarcrm.com>wrote:
>
>> Hi!
>>
>> One of the annoying things I've encountered in working with PHP was
>> dealing with functions having long optional parameter lists, 
>> especially
>> if you need to change only the last one - you have to copy all the
>> defaults. Full named params implementation would solve it, probably, 
>> but
>> before we have that here's an easier solution for part of the 
>> problem:
>>
>> https://wiki.php.net/rfc/skipparams
>>
>> Basically, it allows you to do this:
>>
>> create_query("deleted=0", "name",,, /*report_errors*/ true);
>>
>> Implementation of it is here:
>> https://github.com/smalyshev/php-src/tree/skip_params
>> All things described in RFC seem to be working, please tell me if I
>> forgot anything. If it's accepted I'll also add tests, etc. of 
>> course.
>>
>>
> I would prefer Named parameters, but this is still better than the 
> current
> situation.

Every time a new language construct is proposed, the first arguments 
against are:
- This is confusing syntax
- It is hard to read
- And so one

Stas, and I think you are one of the core developers which raises his 
voice as first, against new language constructs. And now you propose 
such a construct. But the best is you show the optimal solution(named 
parameters) for this problem in your post, and suggests this proposal as 
work around for it. So if this proposal gets implemented and maybe in 
the future named parameters gets also implemented. Have we then two 
solutions for this problem. Or does we revert your current proposal.

Sorry, its not against you but for me it seems more as a quick shot.

Just my 2 cents
Christian