Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96653
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.217.170 cause and error)
MIME-Version: 1.0
In-Reply-To: <402447f2-6007-95c4-6b1d-2bbb30dfdd1d@fleshgrinder.com>
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>
 <402447f2-6007-95c4-6b1d-2bbb30dfdd1d@fleshgrinder.com>
Date: Sun, 30 Oct 2016 16:08:40 +0100
Message-ID: <CADqTB_hH_kxZNyE1K3ZuKPsy9UkqpfuHCEsDDkOXo5iK9889FQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Cc: Nikita Popov <nikita.ppv@gmail.com>, Levi Morrison <levim@php.net>, 
	David Lundgren <dlundgren@syberisle.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Allow Iterator to be used with current, next, reset,
 key functions
From: rasmus@mindplay.dk (Rasmus Schultz)

> 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

In my opinion, that's a completely hypothetical use-case.

If I fetched 1000 records, most likely I'm doing something with those
1000 records.

If I happen to also be doing something special with the first or last
record, why should that require anything special from the collection
object itself?

If we're really this concerned about someone misunderstanding these
functions, I think honestly it would be better to not support
traversables at all - e.g. force them to use iterator_to_array()
instead, which makes it very obvious what's happening.

Perhaps that's a better solution altogether. It also fixes the case
where you accidentally traverse an open record-set twice, e.g. calling
first() and last() on the same iterable - that's not a problem case
you can fix, not even with an interface. In that case, the correct
thing is to fetch the records first, and/or adjust your query, depends
on the use-case, but accidentally iterating twice is likely never the
desired side-effect.

> Another case is every unsorted form of collection, what is first, what is last?

Hypothetical. If it doesn't matter what's first or last, such as in an
unsorted form collection, why would you be calling the first or last
functions?

> How to you determine first and last if the keys of a traversable are objects?

They're the first and last items to come out of the traversable. Seems
pretty straight forward to me.

But either way, I think I'm changing my mind about this one.

And if the these functions support only arrays, then also the names
should probably be array_first() and array_last() for consistency with
other array-only functions.

Perhaps better to make people be explicit, rather than trying to hide
side-effects to achieve shorter syntax...


On Sun, Oct 30, 2016 at 2:14 PM, Fleshgrinder <php@fleshgrinder.com> wrote:
> 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