Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:96645 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 11321 invoked from network); 30 Oct 2016 12:08:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 30 Oct 2016 12:08:00 -0000 Authentication-Results: pb1.pair.com header.from=php@fleshgrinder.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=php@fleshgrinder.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.86 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 77.244.243.86 mx105.easyname.com Received: from [77.244.243.86] ([77.244.243.86:48129] helo=mx207.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 84/BF-25911-E92E5185 for ; Sun, 30 Oct 2016 07:07:59 -0500 Received: from cable-81-173-132-21.netcologne.de ([81.173.132.21] helo=[192.168.178.20]) by mx.easyname.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1c0ou3-00013W-CX; Sun, 30 Oct 2016 12:07:55 +0000 Reply-To: internals@lists.php.net References: <44244cfd-c8ad-e0a9-4e70-380a8a8c940c@syberisle.net> To: Nikita Popov , Rasmus Schultz Cc: Levi Morrison , David Lundgren , internals Message-ID: <01f2f3da-592b-fd23-709d-ad620422f56d@fleshgrinder.com> Date: Sun, 30 Oct 2016 13:07:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Allow Iterator to be used with current, next, reset, key functions From: php@fleshgrinder.com (Fleshgrinder) On 10/30/2016 12:45 PM, Nikita Popov wrote: > On Sun, Oct 30, 2016 at 12:24 PM, Rasmus Schultz wrote: > >> With regards to deprecating array-functions that operate on the >> internal pointer - I'd like to just remind you of the fact that some >> of these functions, reset() and end() in particular, are often used >> not because someone cares about moving the internal pointer, but as a >> means of getting the first/last items of an array. >> >> If the internal pointers are removed, I'd like to suggest we improve >> the reset() and end() functions rather than removing them - there is >> an annoyance with these two functions presently: because they operate >> on the internal pointer, the force you to introduce often meaningless >> intermediary variables. >> >> That is, for example: >> >> $last = end(explode(",", $comma_separated_values)); >> >> Doesn't work. One is forced to introduce a variable: >> >> $parts = explode(",", $comma_separated_values); >> $last = end($parts); >> >> If internal pointers are removed, maybe the reset() and end() >> functions could be made to actually work consistently? Whether applied >> to an expression or variable. >> > > Yeah, I've been thinking about this as well. reset() and end() do seem to > be the most commonly used IAP functions -- while nobody actually cares > about their effect on the IAP. The thing is, if we remove all other > functions that allow users to inspect the IAP, then we can simply change > reset() and end() to return the first/last element. As they would no longer > actually modify the array, they would no longer accept their argument by > reference, so end(explode(...)) would also become legal (and additionally, > they would no longer have to do a full copy of their argument, like they > currently sometimes need to do). > > Nikita > I think it makes much more sense to deprecate all of them and introduce new ones that work in the way we want them to for several reasons. `end()` and `reset()` would have to continue working as they do until the next major release since people who use them might rely on the way they work. This means in effect that nobody can make her PHP 7 code PHP 8 ready up front. Instead we could directly introduce `array_first()` and `array_last()` with the next feature release -- even if the others are not deprecated -- and everyone can update their code or at least use it in new code. Changing `end()` and `reset()` in PHP 7 is imho way to dangerous! Another often asked/proposed question is whether they should accept traversables. I think especially for these two functions it's not easy to simply accept any kind of traversable. Think of an unbuffered database result which is effectively a remote pointer. Retrieving the first and last would mean to iterate all the results. An additional interface should be required for traversables in order to work with first and last. -- Richard "Fleshgrinder" Fussenegger