On 5/3/2016 8:12 PM, Sara Golemon wrote: > The difference with scalar objects is: > A) We need to agree on what methods these objects are going to have. > ((And we won't agree)) >
The nice thing here is that we could start with the things that we agree on and develop it from there further. On 5/3/2016 8:12 PM, Sara Golemon wrote: > We could maybe hedge our bets with a ->invoke(Callable) method that > pushes the value into an arbitrary closure, but that's just adding > complexity to... avoid adding complexity... o.O > That would be pure evil. On 5/3/2016 8:12 PM, Sara Golemon wrote: > B) It's not just about scalars. > > $foo = SomeLibrary::create(...) > |> SomeOtherLibrary::render($$) > |> $foo->send($$); > > Scalar objects don't help this case at all, and since the object > instances are coming from some third-party library, making them > instantiate extended children instead isn't necessarily a trivial > thing (arguments about poorly designed libraries aside). > > I like the scalar objects approach as well. Heck, I wrote one three > years ago: https://github.com/sgolemon/objectifier but I don't think > it solves the same problem space as pipe chaining. > The pipe operator is also just a work around for poorly designed libraries in this case and yields more poorly designed libraries. -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
