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
