On Tue, May 3, 2016 at 9:30 AM, Fleshgrinder <p...@fleshgrinder.com> wrote: > On 5/3/2016 4:53 AM, Terry Cullen wrote: >> Doesn't Nikic's scalar objects (https://github.com/nikic/scalar_objects) >> more or less achieve the same thing while also cleaning up the std lib? >> >> $ret = scandir($arg) >> ->filter(function(){}) >> ->map(function(){}) >> ->merge($someOtherArray); >> > > It is indeed a much better approach. The more I read and think about the > pipe operator the more I am against it. > 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))
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 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. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
