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 "
Just to clarify,
I said it didn't look like it could be a pure AST implementation, and that
it looks like you may need one additional instruction.
It does look that way to me - if only to throw a sensible error
specifically for pipes but also because it makes the imposition of specific
behaviour
On Mon, Jul 5, 2021, at 11:05 AM, Larry Garfield wrote:
> On Sat, Jul 3, 2021, at 9:12 PM, Larry Garfield wrote:
> > On Mon, Jun 7, 2021, at 2:00 PM, Larry Garfield wrote:
> > > Hi folks. Me again.
> > >
> > > A year ago, I posted an RFC for a pipe operator, |>, aka function
> > > concatenation.
On Sat, Jul 3, 2021, at 9:12 PM, Larry Garfield wrote:
> On Mon, Jun 7, 2021, at 2:00 PM, Larry Garfield wrote:
> > Hi folks. Me again.
> >
> > A year ago, I posted an RFC for a pipe operator, |>, aka function
> > concatenation. At the time, the main thrust of the feedback was "cool,
> > like,
On Sun, Jul 4, 2021, at 2:18 AM, Olle Härstedt wrote:
> 2021-07-04 4:12 GMT+02:00, Larry Garfield :
> > On Mon, Jun 7, 2021, at 2:00 PM, Larry Garfield wrote:
> >> Hi folks. Me again.
> >>
> >> A year ago, I posted an RFC for a pipe operator, |>, aka function
> >> concatenation. At the time, the m
2021-07-04 4:12 GMT+02:00, Larry Garfield :
> On Mon, Jun 7, 2021, at 2:00 PM, Larry Garfield wrote:
>> Hi folks. Me again.
>>
>> A year ago, I posted an RFC for a pipe operator, |>, aka function
>> concatenation. At the time, the main thrust of the feedback was "cool,
>> like, but we need partial
On Mon, Jun 7, 2021, at 2:00 PM, Larry Garfield wrote:
> Hi folks. Me again.
>
> A year ago, I posted an RFC for a pipe operator, |>, aka function
> concatenation. At the time, the main thrust of the feedback was "cool,
> like, but we need partial function application first so that the syntax
2021-06-29 0:54 GMT+02:00, Larry Garfield :
> On Mon, Jun 28, 2021, at 5:30 PM, Olle Härstedt wrote:
>
>> Mm. Assoc arrays are by now known to be not so good. I hope...
>
> There are millions of PHP sites build on anonymous arrays today.
>
>> OCaml is strictly evaluated, not lazy like Haskell. So t
> I talked with Joe about this, and the answer is no. Most of the complexity
> comes from the initial "this is a function call, oops no, it's a partial
> call so we switch to doing that instead", which ends up interacting with the
> engine in a lot of different places. Once you've done that, supp
On Mon, Jun 28, 2021, at 5:30 PM, Olle Härstedt wrote:
> Mm. Assoc arrays are by now known to be not so good. I hope...
There are millions of PHP sites build on anonymous arrays today.
> OCaml is strictly evaluated, not lazy like Haskell. So the order might
> matter, dunno, I don't use this oper
2021-06-29 0:06 GMT+02:00, Rowan Tommins :
> On 28/06/2021 21:28, Olle Härstedt wrote:
>> Sorry for hijacking the thread, but are there no other alternatives,
>> really? Just brainstorming:
>>
>> 1) Setting to silence the warning.
>
>
> Just to reiterate: in PHP 8.0, an undefined constant is not a
2021-06-28 23:36 GMT+02:00, Larry Garfield :
> On Mon, Jun 28, 2021, at 3:42 PM, Olle Härstedt wrote:
>> 2021-06-28 22:12 GMT+02:00, Larry Garfield :
>> > On Mon, Jun 28, 2021, at 3:04 PM, Rowan Tommins wrote:
>> >> On 28/06/2021 20:25, Olle Härstedt wrote:
>> >> > Usage (ignoring the pesky undefin
On 28/06/2021 21:28, Olle Härstedt wrote:
Sorry for hijacking the thread, but are there no other alternatives,
really? Just brainstorming:
1) Setting to silence the warning.
Just to reiterate: in PHP 8.0, an undefined constant is not a warning,
it's an error. My apologies to code golfers: yo
On Mon, Jun 28, 2021, at 3:42 PM, Olle Härstedt wrote:
> 2021-06-28 22:12 GMT+02:00, Larry Garfield :
> > On Mon, Jun 28, 2021, at 3:04 PM, Rowan Tommins wrote:
> >> On 28/06/2021 20:25, Olle Härstedt wrote:
> >> > Usage (ignoring the pesky undefined constant warnings ><):
> >>
> >>
> >> Unfortunat
2021-06-28 22:12 GMT+02:00, Larry Garfield :
> On Mon, Jun 28, 2021, at 3:04 PM, Rowan Tommins wrote:
>> On 28/06/2021 20:25, Olle Härstedt wrote:
>> > Usage (ignoring the pesky undefined constant warnings ><):
>>
>>
>> Unfortunately, you can't ignore those warnings; not least because
>> they're fa
2021-06-28 22:04 GMT+02:00, Rowan Tommins :
> On 28/06/2021 20:25, Olle Härstedt wrote:
>> Usage (ignoring the pesky undefined constant warnings ><):
>
>
> Unfortunately, you can't ignore those warnings; not least because
> they're fatal errors in PHP 8, as they frankly should have been in PHP 3.
>
On Mon, Jun 28, 2021, at 3:04 PM, Rowan Tommins wrote:
> On 28/06/2021 20:25, Olle Härstedt wrote:
> > Usage (ignoring the pesky undefined constant warnings ><):
>
>
> Unfortunately, you can't ignore those warnings; not least because
> they're fatal errors in PHP 8, as they frankly should have b
On 28/06/2021 20:25, Olle Härstedt wrote:
Usage (ignoring the pesky undefined constant warnings ><):
Unfortunately, you can't ignore those warnings; not least because
they're fatal errors in PHP 8, as they frankly should have been in PHP 3.
You can use our current ugly callable syntax (stri
2021-06-07 21:00 GMT+02:00, Larry Garfield :
> Hi folks. Me again.
>
> A year ago, I posted an RFC for a pipe operator, |>, aka function
> concatenation. At the time, the main thrust of the feedback was "cool,
> like, but we need partial function application first so that the syntax for
> callable
On Tue, Jun 8, 2021 at 4:09 PM Larry Garfield
wrote:
> On Tue, Jun 8, 2021, at 5:41 AM, Guilliam Xavier wrote:
>
> > you forgot to update one
> > `explode(?)` to `str_split(?)`, and also, the first `fn($v) =>
> > 'strtoupper'` should be just `'strtoupper'`.
>
> I deliberately made that example ex
On Tue, Jun 8, 2021, at 5:41 AM, Guilliam Xavier wrote:
> > Hm. You're right. It used to, but it's been a very long time since
> > explode() allowed an empty split, apparently. I updated the example to use
> > str_split, which is what I'd intended to do in this case. Thanks.
> >
>
> Are you t
Hi,
On Tue, Jun 8, 2021 at 12:09 AM Larry Garfield
wrote:
> On Mon, Jun 7, 2021, at 4:00 PM, Eugene Leonovich wrote:
> > On Mon, Jun 7, 2021 at 9:03 PM Larry Garfield
> > wrote:
> >
> > > https://wiki.php.net/rfc/pipe-operator-v2
> > >
> > FTR, there are several typos in the "Hello World" examp
> On Jun 7, 2021, at 9:39 PM, Larry Garfield wrote:
>
> On Mon, Jun 7, 2021, at 8:09 PM, Mike Schinkel wrote:
>>
>>> On Jun 7, 2021, at 3:00 PM, Larry Garfield wrote:
>>>
>>> Hi folks. Me again.
>>>
>>> A year ago, I posted an RFC for a pipe operator, |>, aka function
>>> concatenation. At
On Mon, Jun 7, 2021, at 8:09 PM, Mike Schinkel wrote:
>
> > On Jun 7, 2021, at 3:00 PM, Larry Garfield wrote:
> >
> > Hi folks. Me again.
> >
> > A year ago, I posted an RFC for a pipe operator, |>, aka function
> > concatenation. At the time, the main thrust of the feedback was "cool,
> > l
> On Jun 7, 2021, at 3:00 PM, Larry Garfield wrote:
>
> Hi folks. Me again.
>
> A year ago, I posted an RFC for a pipe operator, |>, aka function
> concatenation. At the time, the main thrust of the feedback was "cool, like,
> but we need partial function application first so that the synt
On Mon, Jun 7, 2021, at 4:00 PM, Eugene Leonovich wrote:
> On Mon, Jun 7, 2021 at 9:03 PM Larry Garfield
> wrote:
>
> > Hi folks. Me again.
> >
> > A year ago, I posted an RFC for a pipe operator, |>, aka function
> > concatenation. At the time, the main thrust of the feedback was "cool,
> > lik
On Mon, Jun 7, 2021 at 9:03 PM Larry Garfield
wrote:
> Hi folks. Me again.
>
> A year ago, I posted an RFC for a pipe operator, |>, aka function
> concatenation. At the time, the main thrust of the feedback was "cool,
> like, but we need partial function application first so that the syntax for
On 17/05/2016 18:46, Sara Golemon wrote:
On Tue, May 17, 2016 at 4:14 AM, Rowan Collins > wrote: >> On 17/05/2016 11:55, Jesse
Schalken wrote: $id |> >> StringList::decode($$) |> array_replace($$,
$replace) |> >> StringList::encode($$) |> $id; >> >> >> Sara, what do
you think of this tweak, a
On Tue, May 17, 2016 at 5:47 AM, Ryan Pallas wrote:
> Can the place holder be used twice?
>
In the current PR version, no. It adds complexity to the
implementation when dealing with temp vars. In the interest of
keeping the implementation simple, I opted for making the repeated use
of $$ an erro
On Tue, May 17, 2016 at 4:14 AM, Rowan Collins wrote:
> On 17/05/2016 11:55, Jesse Schalken wrote:
> $id
> |> StringList::decode($$)
> |> array_replace($$, $replace)
> |> StringList::encode($$)
> |> $id;
>
>
> Sara, what do you think of this tweak, and my subsequent suggestion that
On 17/05/2016 13:48, Jesse Schalken wrote:
On Tue, May 17, 2016 at 9:14 PM, Rowan Collins mailto:rowan.coll...@gmail.com>> wrote:
To reiterate my comments from earlier in the thread, I think the
"$id = $id" looks really weird here, and spoils the step-by-step
layout - and, in this c
On Tue, May 17, 2016 at 9:14 PM, Rowan Collins
wrote:
> To reiterate my comments from earlier in the thread, I think the "$id =
> $id" looks really weird here, and spoils the step-by-step layout - and, in
> this case, the symmetry.
>
We have the same thing already when chaining methods on value/
On Tue, May 17, 2016 at 6:15 AM, François Laupretre
wrote:
>
>
>
>> The question of function aliases is not so serious because we'll need very
>>> few. Almost every functions have only one 'natural' argument to
>>> substitute
>>> as lhs. I'm not sure I understand what you mean with 'but only in ce
Le 16/05/2016 à 19:53, Sara Golemon a écrit :
I think you're making a false equivalence here. One can see argument
ordering consistency as a serious problem without seeing a Heath
Robinson version of call chaining as the solution to it.
I appreciate that you want to seize onto any opportunity
On 17/05/2016 11:55, Jesse Schalken wrote:
$id = $id
|> StringList::decode($$)
|> array_replace($$, $replace)
|> StringList::encode($$);
To reiterate my comments from earlier in the thread, I think the "$id =
$id" looks really weird here, and spoils the step-by-step layout - and,
Not sure if it's already been mentioned, but I've noticed this operator
would be useful when you want to modify something but need to transform it
before and after.
For example, I have a class that serializes/deserializes arrays of strings,
and I need to modify the array that it has encoded. The c
Hi Sara,
On Apr 30, 2016 3:11 AM, "Sara Golemon" wrote:
>
> This is one of my favorites out of HackLang. It's pure syntactic
> sugar, but it goes a long way towards improving readability.
> https://wiki.php.net/rfc/pipe-operator
After I first read the rfc my immediate feeling was negative. Yet
On Mon, May 16, 2016 at 2:17 AM, François Laupretre wrote:
> Le 16/05/2016 à 03:33, Larry Garfield a écrit :
>> This still sounds awfully complicated to me. I would far, far prefer
>> the $$ syntax to special casing function aliases just to dance around
>> it. If we had a short-function syntax t
Le 16/05/2016 à 03:33, Larry Garfield a écrit :
This still sounds awfully complicated to me. I would far, far prefer
the $$ syntax to special casing function aliases just to dance around
it. If we had a short-function syntax then requiring a piped function
to have only a single argument would
On 05/14/2016 07:42 PM, François Laupretre wrote:
Le 13/05/2016 à 20:16, Sara Golemon a écrit :
for a potential solution to such a long-time issue as argument ordering
sadness, IMHO, it's worth the pain. I am currently doing it and I'll
send
you the list when it is ready.
Awesome. Even if n
Le 13/05/2016 à 20:16, Sara Golemon a écrit :
for a potential solution to such a long-time issue as argument ordering
sadness, IMHO, it's worth the pain. I am currently doing it and I'll send
you the list when it is ready.
Awesome. Even if not used in this feature, it could potentially be
usef
Le 14/05/2016 à 18:35, Sara Golemon a écrit :
On Sat, May 14, 2016 at 3:33 AM, François Laupretre wrote:
Le 14/05/2016 à 01:36, Simon Welsh a écrit :
\>> Sure, you could try to use the type of the value being passed in,
but that ends up much more magic and then you run into the same
problem w
On Sat, May 14, 2016 at 3:33 AM, François Laupretre wrote:
> Le 14/05/2016 à 01:36, Simon Welsh a écrit :
\>> Sure, you could try to use the type of the value being passed in,
>> but that ends up much more magic and then you run into the same
>> problem with strpos, or password_verify, or a variet
Le 14/05/2016 à 01:36, Simon Welsh a écrit :
I’m not fond of this approach. Take in_array as an example. I have,
in the same file, piped an array in as the second argument and
piped a string in as the first. To have the position of the piped
variable be implicit, you’ll need multiple versions of
Le 13/05/2016 à 20:16, Sara Golemon a écrit :
Just to verify, you're suggesting an end-state something like this?
$ret = array(1,2,3)
|> array_map(function($x) { return $x * 2; }) // lhs implicitly
passed as second arg
|> array_sum(); // implicitly passed as only arg (first position)
// $ret
> On 14/05/2016, at 4:16 AM, Sara Golemon wrote:
>
> On Fri, May 13, 2016 at 10:18 AM, François Laupretre wrote:
>>> So we'd have to audit all 4k+ functions in the PHP runtime (and
>>> provide a mechanism for defining it on userspace functions)?
>>
>> That's right, except that, if we only consi
On Fri, May 13, 2016 at 10:18 AM, François Laupretre wrote:
>> So we'd have to audit all 4k+ functions in the PHP runtime (and
>> provide a mechanism for defining it on userspace functions)?
>
> That's right, except that, if we only consider functions accepting more than
> 1 arg, we just need to c
Hi Sara,
Le 13/05/2016 à 00:41, Sara Golemon a écrit :
So we'd have to audit all 4k+ functions in the PHP runtime (and
provide a mechanism for defining it on userspace functions)?
That's right, except that, if we only consider functions accepting more
than 1 arg, we just need to check about 1
On Thu, May 12, 2016 at 11:52 AM, François Laupretre wrote:
> If we restrict usage to function calls, we can quite easily get rid of the $$
> by
> associating to each function the position where the lhs must be inserted
> when used as a 'piped function call'.
>
So we'd have to audit all 4k+ funct
Hi Sara,
Le 12/05/2016 à 19:02, Sara Golemon a écrit :
On Thu, May 12, 2016 at 5:48 AM, Zeev Suraski wrote:
Whether it's $$ or !# or $0 or any other random symbol doesn't really matter.
Agreed.
Here we have a completely optional syntactic sugar,
that's not nearly as widely useful as OOP or
On Thu, May 12, 2016 at 5:48 AM, Zeev Suraski wrote:
> Whether it's $$ or !# or $0 or any other random symbol doesn't really matter.
>
Agreed.
> Here we have a completely optional syntactic sugar,
> that's not nearly as widely useful as OOP or namespaces.
>
Very few things will be as widely usefu
On Thu, May 12, 2016 at 5:33 AM, Quim Calpe wrote:
> Is $0 being considered? It's not ideal but is used as "pattern match
> reference" in preg_replace, so we have a (sort of) precedent here. Same for
> $1 (first capturing subpattern).
>
I don't believe it's been brought up yet, and it'd actually r
> On 12 במאי 2016, at 15:34, Quim Calpe wrote:
>
>> On Thu, May 12, 2016 at 12:33 PM, Davey Shafik wrote:
>>
>> On Thu, May 12, 2016 at 1:19 AM, Larry Garfield
>> wrote:
>>
On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev wrote:
Hi!
> |> seems like a common symbol to
On Thu, May 12, 2016 at 12:33 PM, Davey Shafik wrote:
> On Thu, May 12, 2016 at 1:19 AM, Larry Garfield
> wrote:
>
> > On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev wrote:
> > > Hi!
> > >
> > > > |> seems like a common symbol to use, but it admittedly does look a
> > >
> > > So, usage in
Hi Larry,
On Thu, May 12, 2016 at 8:19 AM, Larry Garfield wrote:
> On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev wrote:
>> Hi!
>>
>> > |> seems like a common symbol to use, but it admittedly does look a
>>
>> So, usage in one semi-obscure language (F#) and one completely obscure
>> one (El
On Thu, May 12, 2016 at 1:19 AM, Larry Garfield
wrote:
> On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev wrote:
> > Hi!
> >
> > > |> seems like a common symbol to use, but it admittedly does look a
> >
> > So, usage in one semi-obscure language (F#) and one completely obscure
> > one (Elixir
Hi!
> If the issue is $$ feels too Perl like, what is the alternative? Is
> there another way to chain methods cleanly?
Well, that's a loaded question. It presumes we already agreed on needing
to chain methods using special syntax outlined in the RFC - which we
didn't - and the only problem is
On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev wrote:
> Hi!
>
> > |> seems like a common symbol to use, but it admittedly does look a
>
> So, usage in one semi-obscure language (F#) and one completely obscure
> one (Elixir) - Clojure doesn't use |> - and one proposal for Javascript
> now qu
Hi!
> |> seems like a common symbol to use, but it admittedly does look a
So, usage in one semi-obscure language (F#) and one completely obscure
one (Elixir) - Clojure doesn't use |> - and one proposal for Javascript
now qualifies for "common". And that counting the fact that neither of
them actu
On 05/09/2016 11:41 AM, Sara Golemon wrote:
On Sun, May 8, 2016 at 11:45 PM, Stanislav Malyshev wrote:
Neither of these is true for |>-$$ thing - it does not have any matches
in any languages I can think of.
You lack imagination. Here's three to get you started:
Elixir:
http://elixir-lang.
Hi!
> You lack imagination. Here's three to get you started:
>
> Elixir:
> http://elixir-lang.org/getting-started/enumerables-and-streams.html#the-pipe-operator
> F#: https://msdn.microsoft.com/en-us/library/dd233229.aspx#Anchor_11
> Clojure: https://clojuredocs.org/clojure.core/-%3E
>
> And i
Hi!
> Are you willing to argue that PHP should never implement features not
> found commonly in other languages? Because that's where you're going
> with that argument.
No, I'm not and no, I'm not. But I do claim it is unobvious - though
that alone would not be the reason to reject it, but I outl
On Sun, May 8, 2016 at 11:45 PM, Stanislav Malyshev wrote:
>> Yep, that's exactly what "->" does. It's just pointless syntactic
>
> No, not really. Calling method on an object is an universally accepted
> phrase in many languages.
>
I never said it wasn't. I said it was pointless syntactic sugar
On 9 May 2016 at 08:45, Stanislav Malyshev wrote:
> Hi!
>
> > I have the feeling that if everyone involved *explicitly* prefixed their
> > opinions with "I think that", this would be a better and more fruitful
>
> Is there any other option?
>
As in "better options"? I don't think so. As in "coul
Hi!
> Yep, that's exactly what "->" does. It's just pointless syntactic
No, not really. Calling method on an object is an universally accepted
phrase in many languages. True, not all of them use ->, and for some of
them -> may have other meaning, but if you tell somebody at least
vaguely familia
1 - 100 of 163 matches
Mail list logo
