On 04/03/2015 10:07, Lester Caine wrote:
On 04/03/15 09:41, Rowan Collins wrote:
Hm, yes, I hadn't thought of the use case of sorting external data. Perhaps we
actually need to specify both interfaces (yes, I realise I'm just inventing
more work here, sorry!) - one for the use case of a custom data structure that
wants to worry about the sort mechanics but not the ordering, and one for the
different use case of wanting to sort something other than PHP values. I
strongly believe that making the first type of object reimplement 11 types of
comparison callback which the engine already has is a bad idea.
I'd been following this thread, but only from a distant need. I tend to
be working with lists pulled directly from a database, and Firebird
allows the selection of collation rules to take care of the bulk of the
problems this interface is also trying to address. This option allows
all of the complication created by unicode to be addressed and a ready
sorted array is provided. The starting point for a generic approach
needs to be based on a unicode rule set which currently we do not have a
standard for. ICU provides a collation system in parallel with the
database standards and if the ICU based string object is adopted then
sort interfaces need to be based on that.
Actually, collation is an interesting point - of all the different sort
functions in current PHP, none of them really considers it.
That's a disadvantage of passing the flags through to the collection
being sorted, rather than the comparison implementation - it's very hard
for us to change the underlying set of sort options without a BC break
on the interface, because they're so closely coupled. For remote data
sources, they'd need a new argument or method to accept and act on the
new options; for simple data structures, they'd want to just use the new
comparison type.
Like so many things, it's probably a good idea to consider up front the
kinds of use cases we're targeting, and those that we're not, otherwise
we end up with an implementation that is very well-engineered in itself,
but doesn't actually meet people's needs.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
