You often need subsets of objects in a collection and want to access them efficiently in your domain model. But you certainly don't want to access the EntityManager or any other object manager here to craft a query. FilterExpressions for collections allow to go back to the database and query for all objects matching the crafted expression. Additionally they also work against in meemory ArrayCollection exactly the same. This way you don't (except for the SQL performance when it haunts you ;)) have to think about the context and can focus on your domain logic.
In Doctrine ORM this will be done by building DQL under the hood, in memory it will be done using Collection#filter(Closure $closure);
- Should allow filtering depending on the "persistence" backend, i.e. in memory for Arraycollection and using sql for PersistentCollection
- Should be very simple to be adoptable in many persistence providers
- Are always either accepting "Expr op Expr" xor "Field op value". A new Expression Language is needed for that, cannot reuse the ORM one.
- Assumes that for "Field" a getter "getField" exists on target object and that the field is mapped in any corresponding persistence provider.
@l3pp4rd if you fetch your entities this way fine, but you should still use this API as then you can ensure that you can use the collection both filtered and unfiltered in the same request without running into troubles about assumptions what is actually in your collection.
@michelsalib Yes i know this interface, however i don't want to implement LINQ fully. First its implemented on language level, so it allows much more features vs a PHP based approach that is on the library level. Second, linq took ages to implement with a huge team. I want this to be a good mix of powerful vs implementable in a reasonable time-frame. Also it should allow us to support many data-providers, so the actual language has to find a least common denominator.