Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84171
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.172 as permitted sender)
Message-ID: <54F48108.6010000@gmail.com>
Date: Mon, 02 Mar 2015 15:26:00 +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>
In-Reply-To: <54F440E6.4050908@gmail.com>
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)

Rowan Collins wrote on 02/03/2015 10:52:
> Thomas Gielfeldt wrote on 02/03/2015 07:43:
>> 2015-02-24 17:17 GMT+01:00 Thomas Gielfeldt <thomas@gielfeldt.dk>:
>>
>>> Hi internals.
>>>
>>> I've made PR proposing a feature request: A new interface Sortable.
>>>
>>> https://github.com/php/php-src/pull/1116
>>>
>>> If possible, I would like to create and RFC describing this in more
>>> detail, and perhaps get a voting on.
>>>
>>> Thanks
>>>
>>> Br,
>>>
>>> Thomas Gielfeldt
>>>
>>>
>> The 2nd PR I made addresses this 
>> (https://github.com/php/php-src/pull/1123),
>> exposing 3 much simpler interfaces depending on what the user 
>> wants/needs
>> to implement, which combined covers all the 11 sort functions.
>>
>> Also, the point of this/these interface(s) is to provide the same power
>> that some of the other SPL interfaces have (Countable, Serializable,
>> ArrayAccess, Iterator, etc.). That is, using native functions with 
>> objects
>> possessing certain capabilities.
>
>
> I don't think a container should be expected to reimplement something 
> as specific as a case-insensitive natural string comparison; its job 
> should be to do the actual sorting of data.
>
> I suggest a single interface with 3 methods: 
> sortValues($cmp_function), sortValuesAssoc($cmp_function), and 
> sortKeys($cmp_function): 
> https://gist.github.com/IMSoP/4ea904203eadf8d5859a
>
> This maintains the obvious connection between userland functions and 
> the method called, and keeps the userland implementation much lower on 
> boilerplate. Conveniently, a collection which internally stores data 
> in an array can pass the callback directly to usort/uasort/uksort for 
> a trivial implementation.
>
> Obviously, this means more implementation needed on the engine side, 
> in that it needs to expose callback functions for the various 
> different comparisons, but I think that's where the comparison logic 
> belongs.


Incidentally, note that this is exactly how the sorting of real arrays 
is done internally: zend_hash_sort_ex [1] takes a comparison callback, 
using a global set by php_set_compare_func [2] for flags, and wrappers 
for things like key vs data comparison [3].

Basically, to implement my suggestion, you need a way to expose the 
php_array_*_compare functions in ext/standard/array.c as callbacks to 
userland, presumably without actually making them named functions.


[1] http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_hash.c#1930
[2] http://lxr.php.net/xref/PHP_TRUNK/ext/standard/array.c#144
[3] http://lxr.php.net/xref/PHP_TRUNK/ext/standard/array.c#173

Regards,
-- 
Rowan Collins
[IMSoP]