Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67721 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 64007 invoked from network); 18 Jun 2013 15:37:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Jun 2013 15:37:47 -0000 Authentication-Results: pb1.pair.com smtp.mail=tjerk.meesters@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=tjerk.meesters@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.181 as permitted sender) X-PHP-List-Original-Sender: tjerk.meesters@gmail.com X-Host-Fingerprint: 209.85.216.181 mail-qc0-f181.google.com Received: from [209.85.216.181] ([209.85.216.181:43271] helo=mail-qc0-f181.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7D/05-24847-8CE70C15 for ; Tue, 18 Jun 2013 11:37:45 -0400 Received: by mail-qc0-f181.google.com with SMTP id u12so2372376qcx.40 for ; Tue, 18 Jun 2013 08:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=WOg0qziIDEUbY49rrdobSRk+dOPWKPuAidiG93GJirI=; b=uOYgvCMRxKtm7wew+UspOskxwsS9uj7WUJ9MQRY2FNsfrYWXFQEguOT5qb9LMkaskE 87fR+KFM6bdeR+4Coaav1EfW3FotcV8ZA6oRTNwpBPqGc4jA8IRxNdiYsHS2LhxeXjF9 THPxScJKyylkSfDJwthV1wpv8xIoI3vyvljpFJYUG2niifM/ITplXoTRB0qvb8dHc87P LCoCESweHh1MvfcFEPsfvwY/fekHXB3w9BECzEkvgqbtftDfXZqN/MTuhs/T+S0MaHZZ 5fD+0RyznhIPvTwqx4awu+4a4v0bQH0BXmA1S4k5DLeQooZhWRLMP1G/44iiYwgbwl/q mzjw== MIME-Version: 1.0 X-Received: by 10.229.141.69 with SMTP id l5mr8754880qcu.23.1371569862428; Tue, 18 Jun 2013 08:37:42 -0700 (PDT) Sender: tjerk.meesters@gmail.com Received: by 10.49.19.68 with HTTP; Tue, 18 Jun 2013 08:37:42 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Jun 2013 23:37:42 +0800 X-Google-Sender-Auth: slh8KJ5UgDy5jxn9a8aLMbaVDH8 Message-ID: To: Sherif Ramadan Cc: Levi Morrison , PHP Internals Content-Type: multipart/alternative; boundary=90e6ba10af856f697204df6f7ec0 Subject: Re: [PHP-DEV] PR 287 - added use_keys argument to array_filter() [Discussion] From: datibbaw@php.net (Tjerk Anne Meesters) --90e6ba10af856f697204df6f7ec0 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 18, 2013 at 11:07 PM, Sherif Ramadan wrote: > On Tue, Jun 18, 2013 at 10:58 AM, Levi Morrison >wrote: > > > > > I'm starting up a thread for discussion on Pull Request 287 > >> https://github.com/php/php-src/pull/287 (allowing array keys to be > passed > >> to the callback function of array_filter through a third optional > boolean > >> argument). I would like to merge this into master and as discussed on > IRC > >> it would probably be a good idea to startup a discussion and make sure > >> there aren't any objections or clarifications not yet voiced. > >> > >> The patch has no BC because the third argument is optional and defaults > to > >> false. Personally, I have always thought it would be a good idea to be > >> able > >> to get the keys into the array_filter callback since I've stumbled > across > >> a > >> few scenarios where that would have made things easier. > >> > >> I'm not sure if there are any particular down sides to this option being > >> added, but none that I can find. It currently passes all tests in master > >> and works as expected. > >> > >> Thoughts, opinions, objections, concerns? > >> > >> > > It might be considered a BC break, but I really think we should drop the > > boolean argument; just have it pass the key as parameter 2 always. > > > > > See the discussion on github for that PR > https://github.com/php/php-src/pull/287#issuecomment-14175109unfortunately > we can't do that as it will break lots of userspace code that might be > doing stuff like array_filter(['foo','','bar'], 'strlen') where strlen only > accepts a single argument and in those cases the result will be triggering > lots of warnings and failed code. > The danger actually lurks in the cases whereby the second argument is accepted and with that (sometimes radically) change the semantics of the function; in fact, quite a few internal functions have this kind of switch-by-argument behaviour, such as "array_keys" to randomly name one. And admittedly, this function when my PR goes through ;-) -- -- Tjerk --90e6ba10af856f697204df6f7ec0--