Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84431
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain luni.fr designates 188.165.39.161 as permitted sender)
Message-ID: <54FC29B4.4000105@luni.fr>
Date: Sun, 08 Mar 2015 11:51:32 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Thomas Gielfeldt <thomas@gielfeldt.dk>, 
 Benjamin Eberlei <kontakt@beberlei.de>
CC: PHP Internals <internals@lists.php.net>
References: <CAGnBX03-qsCySW0qOZFWk60p1MaJe-ed1DN+z2fjAqJJLqu8fg@mail.gmail.com> <CAEPJdu=L2Rx68epUw7NxqrKGcn5Y8Tx+awMLuR8NXG4rct76YA@mail.gmail.com> <CAGnBX01sN6F1t3ntT4qX3a65qxYO3T2Au+8PvWdkrNCX0T-hFw@mail.gmail.com>
In-Reply-To: <CAGnBX01sN6F1t3ntT4qX3a65qxYO3T2Au+8PvWdkrNCX0T-hFw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Feature request and RFC
From: gregory@luni.fr (=?UTF-8?B?R3LDqWdvcnkgUGxhbmNoYXQ=?=)

Le 24/02/2015 20:20, Thomas Gielfeldt a écrit :
> 2015-02-24 17:36 GMT+01:00 Benjamin Eberlei <kontakt@beberlei.de>:
>
>> Hi,
>>
>> On Tue, Feb 24, 2015 at 5:17 PM, Thomas Gielfeldt <thomas@gielfeldt.dk>
>> wrote:
>>
>>> 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.
>>>
>>
>> so you need to implement all methods? This can probably be considered a
>> violation of the Interface Segregation Principle. But adding an interface
>> for each method seems a bit much as well.
>>
>
> Yeah, I've thought of this as well. PHP has got a load of sort functions.
> I've also considered other options:
>
> 1.) 5 interfaces for, respectively, (r)sort, a(r)sort, k(r)sort, u(a|k)sort
> and nat(case)sort, with 2-3 methods per interface.
> 2.) Same as above, but with a flag for reverse instead of a dedicated
> function resulting in 5 interfaces with 1-3 methods each.
> 3.) 1 interface with 2 methods, sort() and usort(), and flags for reverse,
> key and maintaining index.
>
> I did consider the latter much, but wasn't sure if the methods would get
> too monolithic.
>
> I also did consider an interface per method. Briefly. :-)
>
>
>
>>
>>> Thanks
>>>
>>> Br,
>>>
>>> Thomas Gielfeldt
>>>
>>
>>
>

Hi,

I posted a message in the discussion about function names consistency 
which is, in part, related to this thread. The main subject may be 
defining a consistent API, but one part is about ordering native arrays.

http://news.php.net/php.internals/84429

I started to write some documentation for an OO API dedicated to arrays 
- and hence sorting arrays.

https://github.com/gplanchat/php-oop-api/blob/master/doc/array-sorter.md

I wrote in this document an abstract method, named SplArraySorter, which 
only has an abstract sort() method. Every variant implements the 
functionalities of one or multiple array sorting native functions.

The point I want to come after is that the collection should not be 
aware of how we would want to sort it, but let this control to a 
external object.

Therefore, the way collections may be actually sorted would become 
dependent on an external object and be changed on the fly by the program 
itself, without having to rewrite any line of code. This has the 
avantage of letting you have the control over any source code, whether 
you are the author (or able to change it) or if this code comes from a 
dependency (PEAR, Composer, ect...).

So, to make it more visual, I would suggest intead to create the 2 
interfaces Sorter and Sortable, which could be vritten as :

<?php

interface Sortable
{
}

interface Sorter
{
     public function sort(Sortable $collection);
}

Greetings

Grégory Planchat