Re: Re: array_unique optional compare-callback proposal

From: Date: Wed, 20 Nov 2013 20:16:30 +0000
Subject: Re: Re: array_unique optional compare-callback proposal
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-70245@lists.php.net to get a copy of this message 
On Wed, 20 Nov 2013 23:02:39 +0400, Stas Malyshev <smalyshev@sugarcrm.com> wrote:


Hi!


$newArray = array_unique($a, SORT_USERDEFINED, function ($a, $b) {

     return $a->getWrappedObject()->getIdentity() -

$b->getWrappedObject()->getIdentity();
});


Actually my problem was a little different but you get the idea... And I
think there will be even more usecases for this.


What I notice here is that if we add SORT_USERDEFINED, we need to add it
to all other sorts, otherwise it would be inconsistent - why SORT_*
works for all sort functions but SORT_USERDEFINED works only for one of
them? And that opens a bit of a can of worms because for many array
functions this already exists as u* aliases - usort, array_udiff, etc.



Hi,

Actually I have considered implementing another function for this, but there were two things I didn't like: name of the function array_uunique - it just sounds bad and it will cause a lot of mistakes (when you use autocomplete especially), and second - this function will have a lot of copy-pasted stuff from array_unique source (though this is somewhat solvable if I create another function with logic (not exposed to userland)).

But what do you think about this signature then:
array_unique(array $array, int $flag);
array_unique(array $array, Callable $callback);

This is, again, seems inconsistent with all other array_u* functions, but calling a function 'array_uunique' is just something I would prefer to avoid.

Thread (4 messages)

« previous php.internals (#70245) next »