Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84437
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.175 as permitted sender)
Message-ID: <54FC5A71.7000905@gmail.com>
Date: Sun, 08 Mar 2015 14:19:29 +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> <CAEPJdu=L2Rx68epUw7NxqrKGcn5Y8Tx+awMLuR8NXG4rct76YA@mail.gmail.com> <CAGnBX01sN6F1t3ntT4qX3a65qxYO3T2Au+8PvWdkrNCX0T-hFw@mail.gmail.com> <54FC29B4.4000105@luni.fr>
In-Reply-To: <54FC29B4.4000105@luni.fr>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Feature request and RFC
From: rowan.collins@gmail.com (Rowan Collins)

On 08/03/2015 10:51, Grégory Planchat wrote:
> 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);
> }


Empty interfaces are fine for extension-built objects, which under the 
hood implement some particular data structure or whatever that the 
implementation expects, but they're useless for userland classes, 
because there's no way to actually implement them.

If I have a class called UserList, and I want to make it sortable, how 
do I do that with this setup? Again, thinking about different use cases 
might help pin down where this approach would and wouldn't be useful.

Regards,

-- 
Rowan Collins
[IMSoP]