Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:68859 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 94765 invoked from network); 2 Sep 2013 20:11:43 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Sep 2013 20:11:43 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.83 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.83 smtp83.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.83] ([108.166.43.83:36452] helo=smtp83.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 20/0C-29856-EF0F4225 for ; Mon, 02 Sep 2013 16:11:42 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 45948508CB; Mon, 2 Sep 2013 16:11:40 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id E98F1508D4; Mon, 2 Sep 2013 16:11:39 -0400 (EDT) Message-ID: <5224F0FB.9080506@sugarcrm.com> Date: Mon, 02 Sep 2013 13:11:39 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Nikita Popov CC: PHP Internals References: <52243BA6.5040905@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Skipping parameters take 2 From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > I think this doesn't really help readability. Right now you should > implement functions with many options with an $options array. I don't understand. Who says I should do that? I certainly don't see how I should. > If we want to change something here, we should skip this step and go > right for named arguments. I think I'll give implementing them a try. If you are ready to present named args proposal for 5.6, fine. But if not, I think denying obviously requested feature (see links for requests in the RFC) because some "pie in the sky" consideration is completely wrong. I must say it seems a little strange for me given current stream of "because we can" syntax additions proposed to reject something that has been asked for by real people for years just because sometime in the future we might or might not have something that may do a similar thing in different way. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227