Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84436
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
Message-ID: <54FC56AE.3000601@gmail.com>
Date: Sun, 08 Mar 2015 14:03:26 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAGnBX03-qsCySW0qOZFWk60p1MaJe-ed1DN+z2fjAqJJLqu8fg@mail.gmail.com> <CAGnBX03ANKGLM+KpdugxKZBV9hkNUhdsNXWhxkLhG+FK+0-2ww@mail.gmail.com> <54F440E6.4050908@gmail.com> <54F48108.6010000@gmail.com> <CAGnBX02zcVRH5tY=Xugp5Oq-XJQZ0LGR2hKZnSiBG2=HpKGnBw@mail.gmail.com> <D03CC500-2480-42AA-B789-F1E90CDFA8D3@gmail.com> <54F6D96B.7000900@lsces.co.uk>
In-Reply-To: <54F6D96B.7000900@lsces.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Feature request and RFC
From: rowan.collins@gmail.com (Rowan Collins)

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]