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 <kont...@beberlei.de>:
Hi,
On Tue, Feb 24, 2015 at 5:17 PM, Thomas Gielfeldt <tho...@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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
