Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64877 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 2464 invoked from network); 12 Jan 2013 05:57:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Jan 2013 05:57:20 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.147 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.147 smtp147.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.147] ([67.192.241.147:41794] helo=smtp147.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F1/E0-28362-E3BF0F05 for ; Sat, 12 Jan 2013 00:57:19 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp31.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 7B4F7503CB; Sat, 12 Jan 2013 00:57:16 -0500 (EST) X-Virus-Scanned: OK Received: by smtp31.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 24B1C5037A; Sat, 12 Jan 2013 00:57:16 -0500 (EST) Message-ID: <50F0FB3B.2090509@sugarcrm.com> Date: Fri, 11 Jan 2013 21:57:15 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Nikita Popov CC: PHP internals References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [VOTE] array_column() function From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > Voting no, because - even though I like this feature in principle - I think > it's much better solved by introducing list comprehensions (which cover > this and many more cases in a consistent and elegant syntax), which is > something I have planned for 5.6. This is a great illustration of different visions we have here. On one hand, we have practical, immediate feature that covers a clear use case and does not add any constructs or complexity to the core language and services immediate need, covering several lines of frequently encountered boilerplate code with one function. On the other hand, we have a possibility to have in the future a fashionable syntax, which is a bit better, more concise and "cool looking" expression for what foreach already can do. So, my "vision", for example, is that while there's nothing wrong with "cool" language syntaxes and adding them, we should not reject simple practical solutions for them. This is what was done in PHP for years, and I think it is one of the reasons PHP is a great tool for the programmer. Just trying to make my "vision" more clear :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227