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. On Sun, Oct 30, 2016 at 1:47 PM, Fleshgrinder <p...@fleshgrinder.com> wrote: > On 10/30/2016 1:31 PM, Rasmus Schultz wrote: >> On second thought, I agree with that - changing reset() and end() >> doesn't make sense, because people know them and expect them to work >> in a certain way. Likely a lot of people would actually continue to >> use them with intermediary variables the way they do today. Better >> to introduce a new pair of functions, since this will make it clear >> when consumer code depends on the new behavior - if we update the >> existing functions, that means you have to read code knowing which >> version of these very common (and very old) functions you were >> expecting to call. >> >> One thing though, since we have to introduce new functions, I would >> not suggest these be array_first() and array_last(), but rather >> simply first() and last(), and make then work with anything iterable, >> not just arrays. >> > > `first()` and `last()` are extremely generic names and I am still hoping > to see nikic's scalar objects extension to land in core before 8. In > this case one would always call `$x->first()` and `$x->last()`. > Continuing with the `array_` prefix makes perfect sense to me, even if > they accept `\Traversable` instances as well. We also expect `str_` > prefixed functions to accept stringable objects, dont' we. It's just a > prefix for grouping and not necessarily a restrictions regarding the > types the function accepts. > > On 10/30/2016 1:31 PM, Rasmus Schultz wrote: >>> Retrieving the first and last would mean to iterate all the >>> results. >> >> Well, retrieving the last would - retrieving the first would mean >> iterating only over the first result. For a lot of use-cases, and >> unbuffered database results in particular, this is precisely what >> you'd want. >> >>> An additional interface should be required for traversables in >>> order to work with first and last. >> >> I think it would be great to have that as an option - for cases >> where you can and want to optimize retrieval of the last item, but I >> don't think it should be required? For example, in the case of an >> unbuffered database query, there is likely no optimization that can >> be made for last() in the first place, since the database >> client/server are likely using a protocol that doesn't even allow you >> to skip to the last result; in that case, requiring everyone to >> implement a new interface, which does nothing, isn't meaningful. >> > > Not requiring the interface means that we violate the Liskow's > substitution principle, something I see too often in core and successful > PHP software out there. What if a traversable does not want the first > and last to be retrieved in this manner? Throw an exception? This > violates the principle since it is not expected to behave in this way. > Another possibility would it be to return null but then the question is, > was null returned because the first or last element is null or because I > cannot retrieve the first and last. > > Making it explicit is much better. > > -- > Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
