Re: [RFC] Pipe Operator
| From: | Sara Golemon | Date: | Tue, 03 May 2016 18:12:41 +0000 |
| Subject: | Re: [RFC] Pipe Operator | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-93042@lists.php.net to get a copy of this message | ||
On Tue, May 3, 2016 at 9:30 AM, Fleshgrinder <php@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