Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84275
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain gielfeldt.dk from 209.85.217.171 cause and error)
MIME-Version: 1.0
In-Reply-To: <54F48108.6010000@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>
Date: Wed, 4 Mar 2015 08:12:41 +0100
Message-ID: <CAGnBX02zcVRH5tY=Xugp5Oq-XJQZ0LGR2hKZnSiBG2=HpKGnBw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0160a7068986650510712e67
Subject: Re: [PHP-DEV] Re: Feature request and RFC
From: thomas@gielfeldt.dk (Thomas Gielfeldt)

--089e0160a7068986650510712e67
Content-Type: text/plain; charset=UTF-8

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.

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.

3.) I'm probably gonna the one implementing this, and I think this approach
would be much more complex than the two I've already made :-) ... though,
of course, that's not an excuse :-)


That being said, I still like the approach you suggest wrt responsibility
of the interface. I just think that there may be some practical
implications.



>
> [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]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--089e0160a7068986650510712e67--