Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96651
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.84 cause and error)
Reply-To: internals@lists.php.net
References: <44244cfd-c8ad-e0a9-4e70-380a8a8c940c@syberisle.net>
 <CAFMT4Nr+d1k20aY0P9o1G9KU_C9wz2cg2UOPrbE3qbXDBhqe3w@mail.gmail.com>
 <CAF+90c_7g_YdxTfUX8t_OifVJTL=OcvjsC_smWc95M-CcRYaNw@mail.gmail.com>
 <CADqTB_jN6RQxEP5tAJY4T+kuv_rkTzRNvL9T1j-iVX5LG5H3Gg@mail.gmail.com>
 <CAF+90c_rE7DiJ8KEYzFO9GHqx56rin+CiByPe7hRF0fUm-zKBQ@mail.gmail.com>
 <01f2f3da-592b-fd23-709d-ad620422f56d@fleshgrinder.com>
 <CADqTB_jReEH9pGpfKaYnuYiucPcJ7Y+74VL-mNuJJ+THkUFRVA@mail.gmail.com>
 <a6c950d9-9484-a970-3fe4-e03762d108ff@fleshgrinder.com>
 <CADqTB_hd+vL1woB7r2OiNNpCT+2MRthiNw2LzLgjsX1RbbgiHw@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>,
 PHP internals <internals@lists.php.net>
Cc: Nikita Popov <nikita.ppv@gmail.com>, Levi Morrison <levim@php.net>,
 David Lundgren <dlundgren@syberisle.net>
Message-ID: <402447f2-6007-95c4-6b1d-2bbb30dfdd1d@fleshgrinder.com>
Date: Sun, 30 Oct 2016 14:14:14 +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: <CADqTB_hd+vL1woB7r2OiNNpCT+2MRthiNw2LzLgjsX1RbbgiHw@mail.gmail.com>
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 1:59 PM, Rasmus Schultz wrote:
> I think you misunderstand.
> 
> I'm only suggesting that implementing first/last explicitly as an
> optimization be optional.
> 
> If you call first() or last() on a traversable that doesn't implement
> this interface, it will simply traverse the first item or traverse to
> the end.
> 
> In other words, it'll always work, so it doesn't violate anything.
> 
> As said, in a lot of cases, such as traversing a stream of database
> records, there *is* no optimization you can make for last() because
> that's not possible with the driver.
> 
> So in that case, what you're proposing, is that all existing
> traversables, such as DB adapters, shouldn't work with these functions
> at all - everyone should have to go and implement this interface
> first, even for traversable record sets where no optimization can be
> made anyway and all you can do is actually fast-forward to the last
> record by traversing the whole result set anyhow.
> 
> The only thing you'll get by forcing implementation of this interface,
> is no existing traversable will work with these functions.
> 
> In addition, when everyone starts implementing this interface, those
> libraries will lose backwards compatibility, since that interface will
> not be available on older versions.
> 
> All so you can force people to implement an interface that, in many
> cases, contains redundant code that simply traverses the entire result
> set to the last item and returns it, for no meaningful reason.
> 

What I am concerned with is the opt-out case of this functionality. What
if I do not want that somebody misuses an unbuffered result set in such
a way: selecting 1,000 records just to throw 998 away. Your proposal is
very appealing in many ways but the opt-out means that I now need to
trigger a notice or throw an exception because there is no other way to
disallow this functionality.

Especially in the light of unbuffered result sets and generators which
can be traversed only once.

Another case is every unsorted form of collection, what is first, what
is last? How to you determine first and last if the keys of a
traversable are objects? Fail?

There are too many open questions in this regard. It's easier with the
primitive arrays because they have their limitations clearly defined
(maps keep insert order).

First and last only make sense for certain data structures but not for
all. Implementing something that just works might work for 80 % but not
for the rest and they have the problem now. I know that we have no means
to express proper data structures but this will not make it better.
Whether it makes it worse is another question that might help to decide.

-- 
Richard "Fleshgrinder" Fussenegger