On Tue, Jun 3, 2025, at 2:59 AM, Dmitry Derepko wrote:
>>
>> Pipe and compose are importantly different operations. I've had user-space
>> implementations of both available for years in crell/fp:
>> https://github.com/Crell/fp/blob/master/src/composition.php
>> I'd love to have a compose opera
>
>
> Pipe and compose are importantly different operations. I've had
> user-space implementations of both available for years in crell/fp:
> https://github.com/Crell/fp/blob/master/src/composition.php
> I'd love to have a compose operator natively in PHP, too. The RFC for
> that is already wri
On Mon, Jun 2, 2025, at 3:41 PM, Dmitry Derepko wrote:
> Hi Larry!
>
>
>
> It's been a long, long way to get this feature, awesome work.
>
>
>
> Have you considered adding a compose function that does the same thing
> but in the classic PHP function style?
>
>
>
> There's not much difference betwe
Hi Larry!
It's been a long, long way to get this feature, awesome work.
Have you considered adding a compose function that does the same thing but
in the classic PHP function style?
There's not much difference between the new style:
$processor = fn ($data) => htmlentities($data)
|> st
Hello world.
The discussion has been dormant for a while. For now, I'm going to proceed
with the simple-callable approach to pipes, rather than Elixir-style
auto-partialling. I have also added a discussion of a possible future iterator
API built for pipes to the RFC, and another example using
Hi Larry
Sorry again for the delay.
On Fri, Apr 4, 2025 at 6:37 AM Larry Garfield wrote:
>
> * A new iterable API is absolutely a good thing and we should do it.
> * That said, we *need* to split Sequence, Set, and Dictionary into separate
> types. We are the only language I reviewed that didn
On Wed, Apr 9, 2025, at 12:56 AM, Rob Landers wrote:
> On Wed, Apr 9, 2025, at 01:29, Ilija Tovilo wrote:
>> Hi Larry
>>
>> Sorry again for the delay.
>>
>> On Fri, Apr 4, 2025 at 6:37 AM Larry Garfield wrote:
>> >
>> > * A new iterable API is absolutely a good thing and we should do it.
>> > *
On Wed, Apr 9, 2025, at 01:29, Ilija Tovilo wrote:
> Hi Larry
>
> Sorry again for the delay.
>
> On Fri, Apr 4, 2025 at 6:37 AM Larry Garfield wrote:
> >
> > * A new iterable API is absolutely a good thing and we should do it.
> > * That said, we *need* to split Sequence, Set, and Dictionary int
On 03/04/2025 08:22, Larry Garfield wrote:
However, it also received significant pushback off-list from folks who felt it
was too much magic. I don't want to torpedo pipes on over-reaching. But
without feedback from other voters, I don't know if this is over-reaching. Is
it? Please, someon
On Thu, Mar 27, 2025, at 9:30 AM, Ilija Tovilo wrote:
> Hi Larry
>
> Sorry for the late response.
>
> On Fri, Feb 7, 2025 at 5:58 AM Larry Garfield wrote:
>>
>> https://wiki.php.net/rfc/pipe-operator-v3
>
> We have already discussed this topic extensively off-list, so let me
> bring the list up-to
On Thu, Apr 3, 2025, at 4:06 PM, Rowan Tommins [IMSoP] wrote:
> On 03/04/2025 18:06, Larry Garfield wrote:
>> So if we expect higher order functions to be common (and I would probably
>> mainly use them myself), then it would be wise to figure out some way to
>> make them more efficient. Auto-fi
Hi Rowan
On Thu, Apr 3, 2025 at 1:59 PM Rowan Tommins [IMSoP]
wrote:
>
> At first, I thought Ilija's example looked pretty neat, but having
> thought about it a bit more, I think the "first-arg" approach makes a
> handful of cases nicer at the cost of a lot of magic, and making other
> cases wors
On 03/04/2025 18:06, Larry Garfield wrote:
So if we expect higher order functions to be common (and I would probably
mainly use them myself), then it would be wise to figure out some way to make
them more efficient. Auto-first-arg is one way.
From this angle, auto-first-arg is a very limite
On Thu, Apr 3, 2025, at 6:58 AM, Rowan Tommins [IMSoP] wrote:
> On 03/04/2025 08:22, Larry Garfield wrote:
>> However, it also received significant pushback off-list from folks who felt
>> it was too much magic. I don't want to torpedo pipes on over-reaching. But
>> without feedback from other
Hi Ilija and Larry,
thank you so much for your great work bringing PHP forward. I have been
passively reading this list for a while and would like to chime in with two
thoughts.
> Pipes would no longer have the form of expr |> expr, where the
> right-hand-side is expected to return a callable.
Hi Larry
Sorry for the late response.
On Fri, Feb 7, 2025 at 5:58 AM Larry Garfield wrote:
>
> https://wiki.php.net/rfc/pipe-operator-v3
We have already discussed this topic extensively off-list, so let me
bring the list up-to-date.
The current pipes proposal is elegantly simple. This has many
On 11 March 2025 09:00:52 GMT, "Côme Chilliet" wrote:
>This would be way better on performances as a single foreach, no?
>I feel like this pipe operator encourages coders to use array_* functions with
>closures, which is often terrible performances compared to a loop.
I think this highlights
Hello,
I’m also wondering when I see code examples in the RFC like:
$profit = [1, 4, 5]
|> loadMany(...)
|> fn(array $records) => array_map(makeWidget(...), $records)
|> fn(array $ws) => array_filter(isOnSale(...), $ws)
|> fn(array $ws) => array_map(sellWidget(...), $ws)
|> a
Hi
On 2/8/25 12:36, Tim Düsterhus wrote:
If the expression on the right side that produces a Closure has side effects
(output, DB interaction, etc.), then the order in which those side effects
happen may change with the different restructuring.
That is a good point. I see you added a precede
Hi
On 2/26/25 07:26, Larry Garfield wrote:
I have updated the patch and RFC accordingly. I think you're right, it does
make a bit more sense this way.
Is this paragraph in the RFC a left-over from before the change? It
appears redundant with the paragraph before:
The pipe operator has a
On Mon, Feb 10, 2025, at 4:04 AM, Tim Düsterhus wrote:
> Hi
>
> Am 2025-02-07 05:57, schrieb Larry Garfield:
>> https://wiki.php.net/rfc/pipe-operator-v3
>
> After also having taken a look at the implementation and then the
> updated “Precedence” section, I'd like to argue in favor of moving `|>`
Hi
Am 2025-02-07 05:57, schrieb Larry Garfield:
https://wiki.php.net/rfc/pipe-operator-v3
After also having taken a look at the implementation and then the
updated “Precedence” section, I'd like to argue in favor of moving `|>`
to have a higher precedence than the comparison operators (i.e.
On Friday, 7 February 2025 at 04:57, Larry Garfield
wrote:
> Hi folks. A few years ago I posted an RFC for a pipe operator, as seen in
> many other languages. At the time it didn't pass, in no small part because
> the implementation was a bit shaky and it was right before freeze.
> Nonetheles
Hi
On 2/8/25 05:05, Larry Garfield wrote:
Indeed, precendence and associativity need to be mentioned in the RFC.
I've added a precedence section, using examples from the tests and this thread.
Associativity is not explicitly spelled out (though only left
associativity makes sense).
And fo
Hi
On 2/7/25 22:04, Larry Garfield wrote:
I split pipes off from the Composition RFC late last night right before
posting; I guess I missed a few things while doing so. :-/ Most notably, the
Compose section is now removed from pipes, as it is not in scope for this RFC.
(As noted, it's going
On Fri, Feb 7, 2025, at 5:47 PM, Christoph M. Becker wrote:
> On 07.02.2025 at 23:54, Rob Landers wrote:
>
>> Put another way, what is the order of operations for this new operator?
>>
>> For example, what is the output of
>>
>> $x ? $y |> strlen(…) : $z
>>
>> $x + $y |> sqrt(…) . EOL
>>
>> Etc.
On 07.02.2025 at 23:54, Rob Landers wrote:
> Put another way, what is the order of operations for this new operator?
>
> For example, what is the output of
>
> $x ? $y |> strlen(…) : $z
>
> $x + $y |> sqrt(…) . EOL
>
> Etc.
According to the reference implementation[1], that would be equivalent to
On Sat, Feb 8, 2025, at 00:19, Larry Garfield wrote:
> On Fri, Feb 7, 2025, at 4:54 PM, Rob Landers wrote:
>
> > Put another way, what is the order of operations for this new operator?
> >
> > For example, what is the output of
> >
> > $x ? $y |> strlen(…) : $z
> >
> > $x + $y |> sqrt(…) . EOL
>
On Fri, Feb 7, 2025, at 4:54 PM, Rob Landers wrote:
> Put another way, what is the order of operations for this new operator?
>
> For example, what is the output of
>
> $x ? $y |> strlen(…) : $z
>
> $x + $y |> sqrt(…) . EOL
>
> Etc.
>
> I noticed this seems to be missing from the RFC. As a new ope
On Fri, Feb 7, 2025, at 22:04, Larry Garfield wrote:
> Merging a few replies together here, since they overlap. Also reordering a
> few of Tim's comments...
>
> On Fri, Feb 7, 2025, at 7:32 AM, Tim Düsterhus wrote:
> > Hi
> >
> > Am 2025-02-07 05:57, schrieb Larry Garfield:
> >> It is now back
Merging a few replies together here, since they overlap. Also reordering a few
of Tim's comments...
On Fri, Feb 7, 2025, at 7:32 AM, Tim Düsterhus wrote:
> Hi
>
> Am 2025-02-07 05:57, schrieb Larry Garfield:
>> It is now back with a better implementation (many thanks to Ilija for
>> his help an
On Fri, 7 Feb 2025, 21:27 Thomas Hruska, wrote:
> The repeated assignment to $temp in your second example is _not_
> actually equal to the earlier example as you claim. The second example
> with all of the $temp variables should, IMO, just be:
>
> $temp = "Hello World";
> $result = array_filter(
On Fri, Feb 7, 2025, at 10:51 AM, Christoph M. Becker wrote:
>> Of particular note, since the last RFC I have concluded that a compose
>> operator is a necessary complement to a pipe operator. However, it's also
>> going to be notably more work, and the two operators don't actually interact
>>
On 2/6/2025 9:57 PM, Larry Garfield wrote:
Hi folks. A few years ago I posted an RFC for a pipe operator, as seen in many other
languages. At the time it didn't pass, in no small part because the implementation was a
bit shaky and it was right before freeze. Nonetheless, there are now even m
On 07.02.2025 at 05:57, Larry Garfield wrote:
> Hi folks. A few years ago I posted an RFC for a pipe operator, as seen in
> many other languages. At the time it didn't pass, in no small part because
> the implementation was a bit shaky and it was right before freeze.
> Nonetheless, there are
On 2025-02-07 06:57, Larry Garfield wrote:
Hi folks. A few years ago I posted an RFC for a pipe operator, as seen
in
many other languages. At the time it didn't pass, in no small part
because the implementation was a bit shaky and it was right before
freeze.
Nonetheless, there are now even mo
Hi
Am 2025-02-07 05:57, schrieb Larry Garfield:
It is now back with a better implementation (many thanks to Ilija for
his help and guidance in that), and it's nowhere close to freeze, so
here we go again:
https://wiki.php.net/rfc/pipe-operator-v3
There's some editorial issues:
1. Status: D
On Fri, Feb 7, 2025, at 1:36 AM, Eugene Sidelnyk wrote:
> Hi, Larry, That's super! I hope it will pass!
>
> Oladoyinbo, IMO the way it is described right now (e.g. explicit
> closures) is much more elegant than a new way of doing things that's
> not so obvious and will be necessary to keep in min
On Fri, Feb 7, 2025, at 05:57, Larry Garfield wrote:
> Hi folks. A few years ago I posted an RFC for a pipe operator, as seen in
> many other languages. At the time it didn't pass, in no small part because
> the implementation was a bit shaky and it was right before freeze.
> Nonetheless, t
Hi, Larry, That's super! I hope it will pass!
Oladoyinbo, IMO the way it is described right now (e.g. explicit closures)
is much more elegant than a new way of doing things that's not so obvious
and will be necessary to keep in mind and support anyway.
If it'd be necessary to simplify the stuff,
PHP codebase in general is quite unreadable due to robust way of doing
things. Pipe operator might make things more complicated even more...
But after reading the RFC, something came to my mind, a way to simplify
this stuff
What if we implement it this way:
```php
$pipe = " hello world "
41 matches
Mail list logo
