Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84426
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain gielfeldt.dk from 209.85.215.50 cause and error)
MIME-Version: 1.0
In-Reply-To: <D03CC500-2480-42AA-B789-F1E90CDFA8D3@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>
 <D03CC500-2480-42AA-B789-F1E90CDFA8D3@gmail.com>
Date: Sun, 8 Mar 2015 09:57:08 +0100
Message-ID: <CAGnBX00tGh3Pj3aOS7Y5jEzcWt_uTwYworAUewHpjoJr7pbarw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0122aef86e33300510c31b60
Subject: Re: [PHP-DEV] Re: Feature request and RFC
From: thomas@gielfeldt.dk (Thomas Gielfeldt)

--089e0122aef86e33300510c31b60
Content-Type: text/plain; charset=UTF-8

2015-03-04 10:41 GMT+01:00 Rowan Collins <rowan.collins@gmail.com>:

> 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.
>
>
What about a "hybrid" solution? Pass the flags as well as a callback. Then
the implementor can react on the flags if necessary.

https://gist.github.com/gielfeldt/c0ca611f525878c36a65

In this case, I've introduced a new constant for user defined sort.
However, I see a couple of variations on this.

1.) Constant for determining user defined sort (as per the example).
2.) 2 methods, one for usorts, and one for the others (still with both
flags and callbacks). This will result in 6 methods, if we keep it to just
one interface.
3.) 3 interfaces with either one or two methods (option 1 & 2 above).


Regards,
> --
> Rowan Collins
> [IMSoP]
>
>

--089e0122aef86e33300510c31b60--