SPL has priority queues, but they lack a key piece of functionality: the ability to decrease the key of a queue element. A fair number of uses of priority queues depend on this. One example is Djisktra's algorithm. This class is an implementation of a pairing heap, which has performance almost as good as that of a Fibonacci heap, but is considerably simpler to implement.

This class has a few notable differences from the SPL implementations:

• The queue exclusively accepts objects. The reason for this is that it uses SPLObjectStorage as a way to map inserted elements with their tree objects. An elegant method for relaxing this restriction would be a nice improvment.
• It does not implement the Iterator interface. It can if there appears to be a need, but I struggle to see the reason for it. Therefore, I'm KISSing it until proven otherwise.
• Arbitrary elements can be removed. With the pieces in place to reprioritize elements, it seemed an easy task to add what should be a useful ability.

One issue with this pull that I'm not thrilled with, but count as "good enough for now" is the test. It does its job, but is ugly and could use improvements from someone who's better at writing tests.

I see that the library currently implements its own autoload function. Why not just use PSR-4 autoloading and let Composer handle this? It'll make it easier to alter this library while it is on its way to 1.0 and will make it simpler for others to contribute.

If your concern is about performance, your current implementation is a class map. Running composer with the -o flag will generate a class map, instead of attempting to map namespaces to file system locations. Performance should be the same at that point and you'll have DRYer code, as you won't be repeating logic found elsewhere.

There is no last or first method (to retrieve the first or last item, of course) on the set classes. This seems like it'd be something useful to have (and is present in other implementations of sets).

Is it possible to apply multiple filters on arbitrary Collections of this package? I just found a solution to apply a single filter (should be possible by using CallbackFilterIterator).

And is there a preferred or standardised way to sort a collection of objects by a specific attribute?

Couldn't be more convenient, sometimes, to implement Traversable using Iterator?

interface Map extends \ArrayAccess, \Countable, Enumerable { ... } -> interface Map extends \ArrayAccess, \Countable, Collection { ... }

From https://github.com/morrisonlevi/Ardent/blob/master/src/Ardent/Iterator/FilteringIterator.php i notice the following code

    function count() {
        $i = 0;
        for ($this->rewind(); $this->valid(); $this->next()) {
            $i++;
        }
        return $i;
    }

Why just just implement FilteringIterator::$counter has integer and just do basic increment and decrements ?

I've been looking though this library a bit and started wondering why most methods do not have an explicit visibility declared. Is there a reason for using function foo rather than public function foo?

There are places where I am wondering if things are intentionally public or are just missing either private or protected. For instance HashMap::areEqual. This method does not make sense as part of this the public interface of this class. An anonymous function could be used in contains. Though perhaps it is done like this to allow overriding in derivatives of HashMap?

How about enabling testing with https://travis-ci.org/? :)

You have to add a .travis.yml file (example. And enable testing for the repository here: https://travis-ci.org/profile.

• need to update information for package.ini (Onion package builder,bundler)
• if possible, please to move lib/bootstrap.php to other place, since lib/ will be installed to pear directory, the bootstrap.php will be put into path like /opt/local/lib/php/pear/bootstraps.php and will cause namespace pollution.
• if lib to src, then the roles section of package.ini can be ignored.

This is more a bug report than an actual PR.

I tried to add keys() to Map, but I have no clue how to make it work for SortedMap. This hack works for my specific case right now, so maybe including something like it is actually feasible...

Please share your thoughts.

As the title says. One additional change is in the class HashMap, on line 32. The method isEmpty checks against the array count instead of using function empty()

For map implementation, expecially HashMap it advantage for us to define Hashable interface, this interface only require 2 method: hashCode and isEquals modeled after Java. The advantage having this interface are the HashMap no longer take hashfunction argument and move the responsibily of compare two key is equal to the interface. It maybe overkill what do you think?

PR #41 added Mappable and Filterable interfaces – this uses those to specialize functions map and filter. This is experimental as well and would like some feedback if possible.

The idea here is is that some programmers may not want to implement all of the Collection interface. So by using interface segregation we can separate them out.

I'm not completely sold on this idea, though, which is why this is a pull request. I'm hoping to get some feedback.

I would throw an EngineException (PHP7) for consistency with PHP's own type hinting. Or, better, I'd use trigger_error() for PHP5 compatibility (which would presumably result in a EngineException in PHP7)