On Fri, Mar 17, 2023, at 9:45 AM, Larry Garfield wrote:
> On Fri, Mar 17, 2023, at 3:54 AM, Michał Marcin Brzuchalski wrote:
>
>>> As a thought experiment, if we had that syntax and functions that were
>>> designed to be used with them, it would look like so:
>>>
>>> function amap(callable $c,
On Fri, Mar 17, 2023, at 3:54 AM, Michał Marcin Brzuchalski wrote:
>> As a thought experiment, if we had that syntax and functions that were
>> designed to be used with them, it would look like so:
>>
>> function amap(callable $c, iterable $it) { ... }
>> function implode(string $sep, iterable
On Fri, 17 Mar 2023 at 09:52, Robert Landers
wrote:
>
> I think this is already supported-ish. For example, here's a partial
> application in user space that seems to follow all the rules. Or at
> least the rules that are followed make sense.
>
> function partial(Closure $callable, ...$args):
On Thu, Mar 16, 2023 at 11:26 PM Larry Garfield wrote:
>
> On Thu, Mar 16, 2023, at 4:14 AM, Rowan Tommins wrote:
> > On 15/03/2023 21:12, Dan Ackroyd wrote:
> >> Would it be desirable to split those two things into two separate
> >> RFCs, by having the first RFC not have native syntax support,
Hi Larry,
czw., 16 mar 2023 o 23:26 Larry Garfield
napisał(a):
> On Thu, Mar 16, 2023, at 4:14 AM, Rowan Tommins wrote:
> > On 15/03/2023 21:12, Dan Ackroyd wrote:
> >> Would it be desirable to split those two things into two separate
> >> RFCs, by having the first RFC not have native syntax
> On 17 Mar 2023, at 05:33, Larry Garfield wrote:
>
> On Thu, Mar 16, 2023, at 4:14 AM, Rowan Tommins wrote:
>>> On 15/03/2023 21:12, Dan Ackroyd wrote:
>>> Would it be desirable to split those two things into two separate
>>> RFCs, by having the first RFC not have native syntax support, but
On Thu, Mar 16, 2023, at 4:14 AM, Rowan Tommins wrote:
> On 15/03/2023 21:12, Dan Ackroyd wrote:
>> Would it be desirable to split those two things into two separate
>> RFCs, by having the first RFC not have native syntax support, but
>> instead another static method on Closure? e.g. something
On Thu, Mar 16, 2023 at 10:14 AM Rowan Tommins wrote:
>
> On 15/03/2023 21:12, Dan Ackroyd wrote:
> > Would it be desirable to split those two things into two separate
> > RFCs, by having the first RFC not have native syntax support, but
> > instead another static method on Closure? e.g.
On 15/03/2023 21:12, Dan Ackroyd wrote:
Would it be desirable to split those two things into two separate
RFCs, by having the first RFC not have native syntax support, but
instead another static method on Closure? e.g. something like:
Closure::partial($callable, array $position_params, array
On Tue, 14 Mar 2023 at 16:58, Larry Garfield wrote:
>
> New engine approach first, then syntax based on what that approach allows.
Would it be desirable to split those two things into two separate
RFCs, by having the first RFC not have native syntax support, but
instead another static method on
On Tue, Mar 14, 2023 at 12:39 PM Bob Weinand wrote:
>
> > Am 14.03.2023 um 10:16 schrieb Rowan Tommins :
> >
> > On 13/03/2023 20:44, Larry Garfield wrote:
> >> As has been discussed numerous times, all of the most used array
> functions need to be redesigned to work with iterables, and in many
On Tue, Mar 14, 2023 at 5:58 PM Larry Garfield wrote:
>
> On Tue, Mar 14, 2023, at 8:50 AM, Robert Landers wrote:
> > On Tue, Mar 14, 2023 at 1:57 PM Rowan Tommins
> > wrote:
> >>
> >> On Tue, 14 Mar 2023 at 10:39, Bob Weinand wrote:
> >>
> >> > Hey Rowan,
> >> >
> >> > do we actually need
On Tue, Mar 14, 2023, at 8:50 AM, Robert Landers wrote:
> On Tue, Mar 14, 2023 at 1:57 PM Rowan Tommins wrote:
>>
>> On Tue, 14 Mar 2023 at 10:39, Bob Weinand wrote:
>>
>> > Hey Rowan,
>> >
>> > do we actually need *positional* partial application, after a ... token?
>> >
>> > Would it not be
On Tue, Mar 14, 2023 at 1:57 PM Rowan Tommins wrote:
>
> On Tue, 14 Mar 2023 at 10:39, Bob Weinand wrote:
>
> > Hey Rowan,
> >
> > do we actually need *positional* partial application, after a ... token?
> >
> > Would it not be enough, to simply forbid positional arguments after a ...
> > and
On Tue, 14 Mar 2023 at 10:39, Bob Weinand wrote:
> Hey Rowan,
>
> do we actually need *positional* partial application, after a ... token?
>
> Would it not be enough, to simply forbid positional arguments after a ...
> and just allow named arguments? These already have well defined position
>
> Am 14.03.2023 um 10:16 schrieb Rowan Tommins :
>
> On 13/03/2023 20:44, Larry Garfield wrote:
>> As has been discussed numerous times, all of the most used array functions
>> need to be redesigned to work with iterables, and in many cases make more
>> sense. That would be a natural time to
On 13/03/2023 20:44, Larry Garfield wrote:
As has been discussed numerous times, all of the most used array functions need
to be redesigned to work with iterables, and in many cases make more sense.
That would be a natural time to also revisit parameter order to fit with
whatever partial
On Mon, Mar 13, 2023, at 3:36 PM, Rowan Tommins wrote:
> On 13 March 2023 18:44:48 GMT, Robert Landers
> wrote:
>>My approach was more of an iterative one.
>>
>>1. Get left-right done so that
>>
>>$x = something($left, $right, ...);
>>
>>would be allowed, but not
>>
>>$x = something($left, ...,
On 13 March 2023 18:44:48 GMT, Robert Landers wrote:
>My approach was more of an iterative one.
>
>1. Get left-right done so that
>
>$x = something($left, $right, ...);
>
>would be allowed, but not
>
>$x = something($left, ..., $right);
>
>This would bring some immediate benefits, as initially
On Mon, Mar 13, 2023 at 12:28 PM Rowan Tommins wrote:
>
> Hi all,
>
> On Sat, 11 Mar 2023 at 22:48, Robert Landers
> wrote:
>
> > My "syntax sugar" implementation was that this:
> >
> > return $this->cache->get($command->getPhone(), $this->storeOtp($command,
> > ...));
> >
> > gets turned into
Hi all,
On Sat, 11 Mar 2023 at 22:48, Robert Landers
wrote:
> My "syntax sugar" implementation was that this:
>
> return $this->cache->get($command->getPhone(), $this->storeOtp($command,
> ...));
>
> gets turned into this:
>
> return fn(...$x) => $this-cache->get($command->getPhone(),
>
On Fri, Mar 10, 2023 at 10:56 PM Christian Schneider
wrote:
>
> Am 10.03.2023 um 20:04 schrieb Eugene Sidelnyk :
> > Another simplified example:
> >
> > ```
> > // partial application
> > foo(bar(1, ...));
>
> While it is not as concise as your version I think the work-around with short
> arrow
Am 10.03.2023 um 20:04 schrieb Eugene Sidelnyk :
> Another simplified example:
>
> ```
> // partial application
> foo(bar(1, ...));
While it is not as concise as your version I think the work-around with short
arrow functions works ok unless your code is full of partial applications:
On Fri, Mar 10, 2023, at 2:16 PM, Eugene Sidelnyk wrote:
> I glanced over this RFC and suggested syntax has question marks. Each one
> stands for a single parameter.
>
> Since there are named arguments already, it seems to be redundant. We'd
> rather pass couple of named arguments and place the
I glanced over this RFC and suggested syntax has question marks. Each one
stands for a single parameter.
Since there are named arguments already, it seems to be redundant. We'd
rather pass couple of named arguments and place the ... construction at the
ending than twirl around with question marks
On Fri, Mar 10, 2023, at 1:04 PM, Eugene Sidelnyk wrote:
> Hello internals!
> I'm just wondering why First class callable syntax doesn't allow partial
> application?
> Recently I stumbled across following scenario where it could be really
> useful:
>
> ```
> public function
26 matches
Mail list logo
