morrisonlevi / ardent Goto Github PK

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 ?

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?

Using the name contains as a method that take a function is really not very nice from an API perspective. Many collections have specialized ways of finding things that is separate from the normal Collections API. For now, those have been named containsItem or something similar. I'd like to rename containsItem to contains, so I need a new name for the current contains. Looking at the current Collection API, we have names like every and none, so how about one?

And how about renaming every to all?

👍 Congratulations on 50 repo-stars. It's not really an issue, but I wanted to break in the issue tracker

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)

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

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

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).

Hi, this is a feature request / question rather than a bug. Straight to the point:

Does the current implementation allow for an equivalent of Vector<Student>, which would only allow insertion of Student instances (or descendants)?

While it would be a nice and useful feature, I can see how it would complicate both the nomenclature and api if there were implemented as Vector and TypedVector or whatever (and analogies for other templates). Another way would be somewhat like setType() on the current classes, but that feels like it wouldn't properly communicate it's implications once used in code.

I suppose I can always extend the current implementation and override the insert (or equivalent) method with type checking, but it would basically create a class that would have to be copied project to project every time.

Any thoughts on this?

PS: It would be so great for this collection if php actually supported type templates.

Hello ! How to use this library ? And how to use PHPUnit to test code ? Have anyone will tell me ?
Thank you.

These would be useful for people who are interested in using sets for normal set operations instead of simply storing a bunch of unique values.

Hm?

My expectation on a slice is that the keys would be renumbered, since slicing something that doesn't really have an order is sort-of undefined. There needs to be some expectations clearly outlined on this somewhere, and I'm not sure what they should be.

While $preserveKeys = FALSE is default everywhere, wouldn't it be better to break the consistency for Maps? Or better yet, preserve keys by default? It feels like it should be more general use case.

From the user standpoint, I would rather use self describing $map->toArray(). The additional boolean argument is not self explanatory (on first sight, without checking the function declaration). And while $map->toArray($withKeys = TRUE); is readable, it does not really cut the mustard as it's waaaay too long.

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.

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?

Hi,

My Understand of Heap is http://en.wikipedia.org/wiki/Heap_%28data_structure%29 but this is different from http://au.php.net/manual/en/class.splheap.php

A question has also be raised on stackoverflow about the same issue

http://stackoverflow.com/questions/11815649/is-a-php-splheap-really-a-heap

can you give some clarification

Thanks

If I am not wrong, each specific Collection implementation provides a count() method, would be nice to shift it up to the collection interface.

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.

Currently we have names like first and last but also have names like getLeft and getHeight. I'm not sure which convention I'd like to use just yet, but having both rubs me the wrong way.

I would like to see an implementation of enum like it's done with SplEnum or maybe a little bit more elegant (I think) like php-enum.