New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add PipelineBuilderInterface #24
Comments
@GreatOwl the pipeline builder is a rather trivial part of the package. There's also no code consuming the builder. What kind of specialised building mechanisms did you have in mind? My initial thought would be, if specialised building capabilities are desired it could just as well be implemented without implementing an interface, or even by extending the current implementation (I'm not a huge fan of extending, but hey). Since the interface of the builder is rather strict, it only accepts callable types, any alternate implementation would probably implement additional methods. When doing to hinting on the builder interface would not be sufficient when consumer said builder. However, maybe you can provide me with some insights into how you use it and how that fits into creating an interface for the builder. I'm always open to feedback. |
@frankdejonge sure! My initial implementation with modifying the builder was due to the original deficiencies in not having the ability to pass a custom processor. My custom implementation (decorating and creating an interface) allowed me to create a builder that allowed me to wrap every passed stage in a function that provided what I can now do with a custom processor. ie. a short circuit for validation functions. Since clearly processors resolved this, allow me to stretch the concept a bit. A builder is essentially a collection of stages, which anyone can create, which can build a pipeline from those stages. As being a collection, if it were interfaced and tweaked slightly, you could do collection operations on the stages, merging, intersecting, filtering or reducing of the stages. You could then build the stages once and implement repeatedly in different use cases. But then again, maybe I too often take to the feeling of everything should be interfaced. |
Done |
I feel that every part of this library deserves to be Interfaced so that individual applications can choose to implement unique functionality. Hence, I propose interfacing the PipelineBuilder, I'm willing to open a PR myself, but I want to get a sense of what the maintainer's feeling on acceptance would be.
The text was updated successfully, but these errors were encountered: