On 08/03/15 14:03, Rowan Collins wrote: > 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.
One of the advantages that a well designed database provides is that things like 'lower' or 'upper' sort order can be provided and indexed separately to the mixed case base records. One of the things which is unique to Firebird is that a field can be defined with it's own collation rather than the whole database working with a single collation. (Not sure if this is now possible on other engines?) The result is that one can index translated fields in the manor correct for that language rather than having to read the data and resort it. Collation is the tidy way to define a set of sort rules, and even 'up and 'down' may have different results to just reversing the order. Until you drop back to ASCII sorting ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
