Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:68941 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 4793 invoked from network); 7 Sep 2013 10:05:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Sep 2013 10:05:31 -0000 X-Host-Fingerprint: 213.205.241.7 unknown Received: from [213.205.241.7] ([213.205.241.7:23376] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 24/A5-00660-96AFA225 for ; Sat, 07 Sep 2013 06:05:30 -0400 To: internals@lists.php.net,Matthew Leverton Message-ID: <522AFA6A.8010501@mjburgess.co.uk> Date: Sat, 07 Sep 2013 11:05:30 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 213.205.241.7 Subject: Re: [PHP-DEV] [RFC] Named parameters From: michael@mjburgess.co.uk (Michael John Burgess) On 06/09/2013 20:58, Matthew Leverton wrote: > What I don't like about named parameters is that if I build a library, > now even my parameter names are unchangeable if I don't want to break > any backward compatibility, since I never know if somebody will decide > to call my single parameter method with named parameters. Are we > prepared to go through every PHP function and make sure the names of > the parameters are set in stone before this feature would go live? The position of parameters and the name of the function must already be maintained... I dont see why appropriately naming variables is such a burden. Of course, people who use the feature are not going to assume pre-existing code is fair-game from named parameters. As with most new php features, it's to improve code written in the future. Michael