I think this is a great step forward.
With commit signatures required, I think the person who merges a PR
now needs to do so locally. [GitHub CLI](https://cli.github.com/)
helps me a lot to locally checkout a PR quickly, and then
rebase/squash with my own signature.
Thanks to Levi Morrison and Nik
On Mon, 29 Mar 2021, 03:30 Rasmus Lerdorf, wrote:
> On Sun, Mar 28, 2021 at 17:15 Sara Golemon wrote:
>
> > On Sun, Mar 28, 2021 at 6:57 PM Paul Crovella
> > wrote:
> >
> >> You might consider requiring commits be signed while you're at it.
> >>
> >>
> > I suggested this as well, and even if we
On Sun, Mar 28, 2021 at 17:15 Sara Golemon wrote:
> On Sun, Mar 28, 2021 at 6:57 PM Paul Crovella
> wrote:
>
>> You might consider requiring commits be signed while you're at it.
>>
>>
> I suggested this as well, and even if we don't require it, we should
> STRONGLY encourage it.
>
> I've been s
On Sun, Mar 28, 2021 at 6:57 PM Paul Crovella
wrote:
> You might consider requiring commits be signed while you're at it.
>
>
I suggested this as well, and even if we don't require it, we should
STRONGLY encourage it.
I've been signing my commits for several years now, it's not even that
hard.
You might consider requiring commits be signed while you're at it.
On Sun, Mar 28, 2021 at 3:53 PM Nikita Popov wrote:
>
> Hi everyone,
>
> Yesterday (2021-03-28) two malicious commits were pushed to the php-src
> repo [1] from the names of Rasmus Lerdorf and myself. We don't yet know how
> exact
On Mon, Mar 29, 2021 at 12:52 AM Nikita Popov wrote:
> Hi everyone,
>
> Yesterday (2021-03-28) two malicious commits were pushed to the php-src
> repo [1] from the names of Rasmus Lerdorf and myself. We don't yet know how
> exactly this happened, but everything points towards a compromise of the
Hi everyone,
Yesterday (2021-03-28) two malicious commits were pushed to the php-src
repo [1] from the names of Rasmus Lerdorf and myself. We don't yet know how
exactly this happened, but everything points towards a compromise of the
git.php.net server (rather than a compromise of an individual gi
> Now that I see their implementation again, I'm wondering if
> `IntlDateTimePatternGenerator` is the right name, or we should also use
> `IntlDatePatternGenerator`, which is more in line with `IntlDateFormatter`.
I was also wondering about that. I ended up going for
`IntlDateTimePatternGenera
Now that I see their implementation again, I'm wondering if
`IntlDateTimePatternGenerator` is the right name, or we should also use
`IntlDatePatternGenerator`, which is more in line with `IntlDateFormatter`.
I was also wondering about that. I ended up going for
`IntlDateTimePatternGenerat
Hi Mel,
Thank you very much for working on this! I was bitten by lack of this
functionality a few years ago, and I couldn't find any (good) alternative.
Thus, I'm looking forward to having `IntlDateTimePatternGenerator` in
ext/intl.
I think it could be mentioned for those who don't open the bug r
On Sun, Mar 28, 2021, at 7:34 AM, Deleu wrote:
> >
> > but then we can bring up the side running RFC from
> > Larry which proposes to make the same short syntax available for other
> > function declarations, how would this work then with this mindset of
> > `fn` meaning auto capture? Does that mean
On 25/03/2021 16:25, Larry Garfield wrote:
So in conclusion, it seems the reasons closures weren't auto-capture always
were:
1) Possible performance concerns that are no longer relevant.
2) Avoid surprise references.
3) Allow users to capture by value or by reference.
I wasn't involved in th
Hi Internals,
I have written a new proposal in the series of improvements to mysqli
extension. This one aims to add a new method mysqli_result::fetch_column as
well as its functional counterpart.
https://wiki.php.net/rfc/mysqli_fetch_column
The RFC is very simple, but I am looking for your opini
Hello Internals,
I would like to propose an addition to the intl extension,
IntlDateTimePatternGenerator.
ICU exposes the DateTimePatternGenerator class that allows generating a
formatting pattern from a given "skeleton" for a given locale. (see
https://unicode-org.github.io/icu-docs/apidoc/dev
> On Mar 28, 2021, at 8:04 AM, Kalle Sommer Nielsen wrote:
>
> Den søn. 28. mar. 2021 kl. 14.30 skrev Deleu :
>>
>> The fact that short closure is inconsistent with the rest of PHP is a done
>> deal since the voting passed prior to 7.4 release. Unless there's a
>> follow-up to deprecate the
>
> but then we can bring up the side running RFC from
> Larry which proposes to make the same short syntax available for other
> function declarations, how would this work then with this mindset of
> `fn` meaning auto capture? Does that mean a procedural function
> declared with `fn` will now inhe
Den søn. 28. mar. 2021 kl. 14.30 skrev Deleu :
>
> The fact that short closure is inconsistent with the rest of PHP is a done
> deal since the voting passed prior to 7.4 release. Unless there's a follow-up
> to deprecate the 7.4 short closure auto capture without `auto` keyword and
> make it loo
On 24.03.2021 17:19, Larry Garfield wrote:
> 1) The updated short-functions RFC: https://wiki.php.net/rfc/short-functions
> 2) A new RFC, code by Nuno, for auto-capturing multi-statement closures:
> https://wiki.php.net/rfc/auto-capture-closure
I'm not sure just the keyword (`fn`) should indicate
The fact that short closure is inconsistent with the rest of PHP is a done
deal since the voting passed prior to 7.4 release. Unless there's a
follow-up to deprecate the 7.4 short closure auto capture without `auto`
keyword and make it look like PHP can't make up it's mind, I feel that your
perspec
On 27.03.21 17:05, Rowan Tommins wrote:
My biggest concern with automatic capture is the potential for
*accidentally* capturing variables - that is, intending to introduce a
local variable inside the closure, but capturing a variable from the
outer scope that happens to have the same name. This i
Den søn. 28. mar. 2021 kl. 13.02 skrev Deleu :
>
> This would lead to inconsistent behavior in the language when short closures
> auto capture without the auto keyword while multi statements closure doesn't.
> One of the best features of these RFC are their cognitive definition that is
> clear, c
This would lead to inconsistent behavior in the language when short
closures auto capture without the auto keyword while multi statements
closure doesn't.
One of the best features of these RFC are their cognitive definition that
is clear, concise, consistent and simple.
On Sun, Mar 28, 2021, 11:26
Hi Rowan
Den lør. 27. mar. 2021 kl. 18.05 skrev Rowan Tommins :
> Based on those, there seems to be no way to prevent a variable being
> captured, even if its value is immediately discarded each time the
> closure runs. This may be less than ideal:
>
> $results = getLargeReportFromDatabase();
> //
On Sat, Mar 13, 2021 at 6:30 PM tyson andre
wrote:
> Hi internals,
>
> I've created a new RFC https://wiki.php.net/rfc/debug_backtrace_depth to
> return the depth of the current stack trace.
>
> Inspecting the current stack trace depth is occasionally useful for
> 1. Manually debugging with tempo
24 matches
Mail list logo
