While working on any (well, most) web application you will come across transactions. You know, so that your data couldn’t end in a malformed state. The idea of a transaction is easily understandable. You start it, do a bunch of stuff and then either “commit” (persist changes you did while in the transaction) or “rollback” (discard the changes) it. The concept is most commonly used when communicating with databases, but is not limited just to it. You could for example write a API client that could rollback the changes it did (like deleting a user it created and such).
So…
This is more of a rant about how we (not limited to, but including PHP community) have been designing our packages than a real article. So, i bet as anyone right now, when you are writing a project you are depending on bunch of packages/libraries people have created and you are using composer to manage your dependencies. This is all fine an you should keep doing that as it’s the best way to manage your dependencies and will save you the time you would spent reinventing the wheel.
Now the not so good parts. If you are a big framework…
This article will talk about current state of collection pipeline libraries in PHP. It will go over the introduction what a collection pipeline actually is, then it will go over some of the libraries that are available in Packagist and will reason about why i created another one of these. In the follow up articles i will cover their usage in the wild and refactoring loops into collection.
Introduction to collection pipelines
Some time last year i was reading an article by Martin Fowler named Refactoring with Loops and Collection Pipelines and it’s enough to say that i was really impressed with the readability…
