Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84284
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <CAGnBX02zcVRH5tY=Xugp5Oq-XJQZ0LGR2hKZnSiBG2=HpKGnBw@mail.gmail.com>
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>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Wed, 04 Mar 2015 09:41:16 +0000
To: Thomas Gielfeldt <thomas@gielfeldt.dk>
CC: PHP Internals <internals@lists.php.net>
Message-ID: <D03CC500-2480-42AA-B789-F1E90CDFA8D3@gmail.com>
Subject: Re: [PHP-DEV] Re: Feature request and RFC
From: rowan.collins@gmail.com (Rowan Collins)

On 4 March 2015 07:12:41 GMT, Thomas Gielfeldt <thomas@gielfeldt.dk> wrote:
>2015-03-02 16:26 GMT+01:00 Rowan Collins <rowan.collins@gmail.com>:
>
>> 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.
>>
>>
>Though I can appreciate the elegance in what you propose, I'm worried
>about
>a couple of things with this approach.
>
>1.) Having to pass a comparison function through userland, could hurt
>performance for the ArrayObject, which otherwise would use the native C
>sort functions directly on its hashtable.

Anything implemented in a C extension can still do so, just as they can overload property access or Traversable behaviour. This interface is only necessary when implementing the sort logic in userland anyway.

>2.) This approach forces the implementor to rely on a userland
>comparison
>function. While this would not be a problem for the specific use case I
>had
>in mind, it could destroy the possibility of further abstraction. One
>example could be a sort in conjunction with a database class. Probably
>not
>the best example, but I hope you understand what I'm getting at.
>Dispatching the sort to something outside PHP. If all that the sort
>methods
>get are closures, then it's near impossible to determine the intent of
>the
>caller.

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.

Regards,
-- 
Rowan Collins
[IMSoP]