Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64913 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 25638 invoked from network); 12 Jan 2013 23:57:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Jan 2013 23:57:31 -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 67.192.241.183 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.183 smtp183.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.183] ([67.192.241.183:41089] helo=smtp183.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 00/50-24212-B68F1F05 for ; Sat, 12 Jan 2013 18:57:31 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp18.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 39D5F2680BD; Sat, 12 Jan 2013 18:57:29 -0500 (EST) X-Virus-Scanned: OK Received: by smtp18.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 745912680BB; Sat, 12 Jan 2013 18:57:28 -0500 (EST) Message-ID: <50F1F867.9040503@sugarcrm.com> Date: Sat, 12 Jan 2013 15:57:27 -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: <50F0FB3B.2090509@sugarcrm.com> 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! > Stas, I think you are misrepresenting this a bit. It's not about adding > something "cool looking", it's about adding a feature that solves *this > and many more* problems in a consistent way. A way that does *not* > require to add a new function for every single array manipulation. We already have a way that works with arrays without adding functions. It's called foreach(). However, *some* ways of manipulating arrays are encountered very frequently, and it is a long-standing tradition of PHP to provide shortcut functions for such functionality. > I know that not everyone agrees with that philosophy, but I personally > don't like to add new features that can be easily covered by more > general solutions, or features that just represent a hack because the That's why I am talking about difference in visions. I prefer practical solution for immediate needs, you think it is never needed as long as there is a general solution and the practical need can be implemented using it, even if the code will be longer and requires more work from the person implementing it. > That's why I think that this is not necessary. It will be hopefully > properly handled in the future and until then this function is trivial > enough to just write it yourself. I don't see how we need yet another Most of array_* functions can be trivially written using foreach() or some other form of loop. That, in my opinion, does not detract from their usefulness. And if we look at the history of PHP, that has long been the tradition. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227