Re: [PHP-DEV] Changes to Git commit workflow
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 Nikita for the very quick response. > > 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 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. > > > > > I think for php-src commits we can require it. For doc and other repos we > > can make it optional for now until people are more comfortable with it. > > > > -Rasmus > > > > > > We can require Signed Commits for the main active branches on GitHub: > > https://docs.github.com/en/github/administering-a-repository/about-protected-branches#require-signed-commits > > > We can create rules that requires that for all active maintained version of > PHP. > > We can set that per repo, or in a organization level. > > - Gabriel Caruso -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Changes to Git commit workflow
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 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. > > > I think for php-src commits we can require it. For doc and other repos we > can make it optional for now until people are more comfortable with it. > > -Rasmus > > We can require Signed Commits for the main active branches on GitHub: > https://docs.github.com/en/github/administering-a-repository/about-protected-branches#require-signed-commits We can create rules that requires that for all active maintained version of PHP. We can set that per repo, or in a organization level. - Gabriel Caruso
Re: [PHP-DEV] Changes to Git commit workflow
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 signing my commits for several years now, it's not even that > hard. > I think for php-src commits we can require it. For doc and other repos we can make it optional for now until people are more comfortable with it. -Rasmus
Re: [PHP-DEV] Changes to Git commit workflow
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.
Re: [PHP-DEV] Changes to Git commit workflow
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 > exactly this happened, but everything points towards a compromise of the > git.php.net server (rather than a compromise of an individual git account). > > While investigation is still underway, we have decided that maintaining our > own git infrastructure is an unnecessary security risk, and that we will > discontinue the git.php.net server. Instead, the repositories on GitHub, > which were previously only mirrors, will become canonical. This means that > changes should be pushed directly to GitHub rather than to git.php.net. > > While previously write access to repositories was handled through our > home-grown karma system, you will now need to be part of the php > organization on GitHub. If you are not part of the organization yet, or > don't have access to a repository you should have access to, contact me at > ni...@php.net with your php.net and GitHub account names, as well as the > permissions you're currently missing. Membership in the organization > requires 2FA to be enabled. > > This change also means that it is now possible to merge pull requests > directly from the GitHub web interface. > > We're reviewing the repositories for any corruption beyond the two > referenced commits. Please contact secur...@php.net if you notice anything. > > Regards, > Nikita > > [1]: > https://github.com/php/php-src/commit/c730aa26bd52829a49f2ad284b181b7e82a68d7d > and > https://github.com/php/php-src/commit/2b0f239b211c7544ebc7a4cd2c977a5b7a11ed8a -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Changes to Git commit workflow
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 > git.php.net server (rather than a compromise of an individual git > account). > > While investigation is still underway, we have decided that maintaining > our own git infrastructure is an unnecessary security risk, and that we > will discontinue the git.php.net server. Instead, the repositories on > GitHub, which were previously only mirrors, will become canonical. This > means that changes should be pushed directly to GitHub rather than to > git.php.net. > > While previously write access to repositories was handled through our > home-grown karma system, you will now need to be part of the php > organization on GitHub. If you are not part of the organization yet, or > don't have access to a repository you should have access to, contact me at > ni...@php.net with your php.net and GitHub account names, as well as the > permissions you're currently missing. Membership in the organization > requires 2FA to be enabled. > > This change also means that it is now possible to merge pull requests > directly from the GitHub web interface. > > We're reviewing the repositories for any corruption beyond the two > referenced commits. Please contact secur...@php.net if you notice > anything. > > Regards, > Nikita > Assuming you do already have write access on GitHub, you can change the upstream repository of your local clone by running "git remote set-url origin g...@github.com:php/php-src.git" (replacing php/php-src with the repository in question). Nikita
[PHP-DEV] Changes to Git commit workflow
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 git account). While investigation is still underway, we have decided that maintaining our own git infrastructure is an unnecessary security risk, and that we will discontinue the git.php.net server. Instead, the repositories on GitHub, which were previously only mirrors, will become canonical. This means that changes should be pushed directly to GitHub rather than to git.php.net. While previously write access to repositories was handled through our home-grown karma system, you will now need to be part of the php organization on GitHub. If you are not part of the organization yet, or don't have access to a repository you should have access to, contact me at ni...@php.net with your php.net and GitHub account names, as well as the permissions you're currently missing. Membership in the organization requires 2FA to be enabled. This change also means that it is now possible to merge pull requests directly from the GitHub web interface. We're reviewing the repositories for any corruption beyond the two referenced commits. Please contact secur...@php.net if you notice anything. Regards, Nikita [1]: https://github.com/php/php-src/commit/c730aa26bd52829a49f2ad284b181b7e82a68d7d and https://github.com/php/php-src/commit/2b0f239b211c7544ebc7a4cd2c977a5b7a11ed8a
Re: [PHP-DEV] Proposal: add IntlDateTimePatternGenerator
> 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 `IntlDateTimePatternGenerator`, because ICU has that same inconsistency (`icu::DateFormat` and `icu::DateTimePatternGenerator`). I think the big argument here is discoverability - if someone is wondering about whether PHP exposes the feature from ICU, it might be harder to find it if we name it differently (and vice versa). PS: Sorry about the duplicate/badly formatted message - I am new to the concept of mailing lists. - Original Message - From: "Máté Kocsis" To: "Mel Dafert" Cc: "internals" Sent: Sunday, March 28, 2021 7:45:46 PM Subject: Re: [PHP-DEV] Proposal: add IntlDateTimePatternGenerator 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 report that HHVM implemented this class long ago: https://github.com/facebook/hhvm/commit/bc84daf7816e4cd268da59d535dcadfc6cf01085 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`. Regards: Máté Mel Dafert ezt írta (időpont: 2021. márc. 28., V, 16:54): -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: add IntlDateTimePatternGenerator
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
`IntlDateTimePatternGenerator`, because ICU has that same inconsistency
(`icu::DateFormat` and `icu::DateTimePatternGenerator`). I think the big
argument here is discoverability - if someone is wondering about whether PHP
exposes the feature from ICU, it might be harder to find it if we name it
differently (and vice versa).
From: "Máté Kocsis"
To: "Mel Dafert"
Cc: "internals"
Sent: Sunday, March 28, 2021 7:45:46 PM
Subject: Re: [PHP-DEV] Proposal: add IntlDateTimePatternGenerator
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 report that HHVM
implemented this class long ago: [
https://github.com/facebook/hhvm/commit/bc84daf7816e4cd268da59d535dcadfc6cf01085
|
https://github.com/facebook/hhvm/commit/bc84daf7816e4cd268da59d535dcadfc6cf01085
]
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`.
Regards:
Máté
Mel Dafert < [ mailto:m...@dafert.at | m...@dafert.at ] > ezt írta (időpont:
2021. márc. 28., V, 16:54):
BQ_BEGIN
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/icu4c/classicu_1_1DateTimePatternGenerator.html
|
https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/classicu_1_1DateTimePatternGenerator.html
] )
This allows more flexibility than the current $format argument of
IntlDateFormatter::format(), which takes either a few pre-defined constants or
a hard-coded format.
This functionality also has been requested in the past. (see [
https://bugs.php.net/bug.php?id=70377 | https://bugs.php.net/bug.php?id=70377 ]
)
For example, if an application requires a format that will always use the long
version of a year, but the short version of a month (eg. "MM/dd/" for
"en_US", or "dd.MM." for "de_DE"), one is out of luck.
IntlDateFormatter::SHORT will use the short year for "de_DE" ("dd.MM.YY"), and
IntlDateFormatter::MEDIUM will use the long version of a month for "en_US"
("MMM dd, ").
With IntlDateTimePatternGenerator::getBestPattern(), a skeleton can be provided
to generate the appropriate pattern for a given locale.
In the use-case given above, the skeleton "MMdd" will generate the desired
patterns for each locale, which can then be passed to
IntlDateFormatter::format().
Proposed Signature:
```
class IntlDateTimePatternGenerator
{
public function __construct(?string $locale = null) {}
public static function create(?string $locale = null):
?IntlDateTimePatternGenerator {}
public function getBestPattern(string $skeleton): string|false {}
}
```
Example use-case:
```
$date = new \DateTime();
$skeleton = "MMdd";
$dtpg = new \IntlDateTimePatternGenerator(); // uses default locale if not
specified
$format = $dtpg->getBestPattern($skeleton);
echo \IntlDateFormatter::formatObject($date, $format); // outputs "28.03.2020"
for "de_DE" locale
```
The proposed implementation can be found here: [
https://github.com/php/php-src/pull/6771 |
https://github.com/php/php-src/pull/6771 ]
I assume that this will require an RFC, in which case I request the karma to
create one. My wiki account is deltragon.
Regards,
Mel Dafert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: [ https://www.php.net/unsub.php |
https://www.php.net/unsub.php ]
BQ_END
Re: [PHP-DEV] Proposal: add IntlDateTimePatternGenerator
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 report that
HHVM implemented this class long ago:
https://github.com/facebook/hhvm/commit/bc84daf7816e4cd268da59d535dcadfc6cf01085
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`.
Regards:
Máté
Mel Dafert ezt írta (időpont: 2021. márc. 28., V, 16:54):
> 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/icu4c/classicu_1_1DateTimePatternGenerator.html
> )
> This allows more flexibility than the current $format argument of
> IntlDateFormatter::format(), which takes either a few pre-defined constants
> or a hard-coded format.
> This functionality also has been requested in the past. (see
> https://bugs.php.net/bug.php?id=70377)
>
> For example, if an application requires a format that will always use the
> long version of a year, but the short version of a month (eg. "MM/dd/"
> for "en_US", or "dd.MM." for "de_DE"), one is out of luck.
> IntlDateFormatter::SHORT will use the short year for "de_DE" ("dd.MM.YY"),
> and IntlDateFormatter::MEDIUM will use the long version of a month for
> "en_US" ("MMM dd, ").
>
> With IntlDateTimePatternGenerator::getBestPattern(), a skeleton can be
> provided to generate the appropriate pattern for a given locale.
> In the use-case given above, the skeleton "MMdd" will generate the
> desired patterns for each locale, which can then be passed to
> IntlDateFormatter::format().
>
> Proposed Signature:
> ```
> class IntlDateTimePatternGenerator
> {
> public function __construct(?string $locale = null) {}
>
> public static function create(?string $locale = null):
> ?IntlDateTimePatternGenerator {}
>
> public function getBestPattern(string $skeleton): string|false {}
> }
> ```
>
> Example use-case:
> ```
> $date = new \DateTime();
> $skeleton = "MMdd";
> $dtpg = new \IntlDateTimePatternGenerator(); // uses default locale if not
> specified
> $format = $dtpg->getBestPattern($skeleton);
>
> echo \IntlDateFormatter::formatObject($date, $format); // outputs
> "28.03.2020" for "de_DE" locale
>
> ```
>
> The proposed implementation can be found here:
> https://github.com/php/php-src/pull/6771
> I assume that this will require an RFC, in which case I request the karma
> to create one. My wiki account is deltragon.
>
> Regards,
> Mel Dafert
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2
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 a procedural function
> > declared with `fn` will now inherit the scope from which it was
> > declared (usually the global scope)? What about methods declarations,
> > do they import properties into the local scope? How does traits
> > interact here, same as methods?
> >
>
> I think I remember the 1st version of Larry's RFC proposing `public fn
> classMethod(): bool => $this->myAttr;` as a class method which seems to
> match what you're trying to say here, but that has been withdrawn and the
> RFC no longer proposes the fn keyword for class methods or function
> declarations, which is discussed under *Background* of RFC
> https://wiki.php.net/rfc/auto-capture-closure. Larry and Nuno may correct
> me if I'm wrong but as far as I understood, that change happened to address
> exactly the points you're describing here: what does `public fn
> classMethod(): bool` would capture? There's actually little to no reason to
> do it. Larry's RFC still proposes a great improvement for
> getters/setters/short methods and Nuno's RFC allows us to write code that
> is naturally expected to work, such as `fn () => {...}`.
>
> As for making `fn` an alias of `function` I believe that is already broken
> because of 7.4 arrow functions. As you describe, that would be "an
> exception" to PHP syntax, but more pressing it means that we would be
> wasting the potential of 2 separate keywords having different goals. I
> think it was Nikita that once said that we have a very limited budget on
> what we can do/offer through programming syntax and throwing `fn` out would
> be such a waste of that limited budget.
>
> --
> Marco Aurélio Deleu
The short-functions RFC as initially proposed had two variants, one which just
used =>, and one with used both => and fn. Personally I don't have that strong
of a feeling about function vs fn in that case. However, when discussing with
Nuno using "fn" to indicate auto-capture made the most sense, as => already
very clearly means "evaluates to expression."
I'm personally not wedded to any specific syntax, as long as the net result is
consistent and self-evident to both writers and readers, and allows for both
auto-capturing lambdas and expression-style functions.
I'm not wild about function and fn being universally synonymous. As Mike
notes, it would create another coding style battlefront of when you should use
one or the other since both are synonymous. What we'd likely end up with is
drifting toward the whole language using fn because it's easier to type, but
not everyone, so you'd have a lot of inconsistency between projects. If
function and fn mean different things, there is no room for subjective
preference. You use the keyword that means the behavior you want.
As a thought experiment, let's play with the "auto" keyword for a moment. (As
I'm typing this I don't know what it will produce.)
$c = 1;
// Existing syntax.
$f = function($a, $b) use ($c) {
return $a * $b * $c * $this->d;
};
// If you want to DISABLE object binding.
$d = $this->d;
$f = static function($a, $b) use ($c, $d) {
return $a * $b * $c * $d;
};
// If you want to ENABLE auto-capture.
$f = auto function($a, $b) {
return $a * $b * $c * $this->d;
};
// If you want to DISABLE object binding but ENABLE auto-capture.
$d = $this->d;
$f = static auto function($a, $b) {
return $a * $b * $c * $d;
};
So we end up with one enable toggle and one disable toggle. That's generally
considered a bad idea. It also means that what I believe is *usually* the most
common desired configuration (don't capture $this, but capture anything else)
the one that involves the most typing.
That doesn't seem ideal.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and short functions take 2
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 the discussion when anonymous functions were first added, but I was during the discussions that led to the current arrow functions. I think it's important context that multi-statement closures were originally included and explicitly removed, precisely because automatic capture was always controversial. It is perfectly reasonable to re-visit the topic now, but it is not, as some seem to be implying, one that has already been agreed in principle. Bob's original "Short Closures" RFC [1] in 2015 included both single expressions and full function bodies. As in subsequent discussions, some people thought implicit capture was a great feature, and others were concerned by it. Rasmus described it [2] as "breaking [a] longstanding basic tenet of the language". There were other reasons that RFC was not accepted, mostly around syntax, but several people in the voting thread [3] gave automatic capture as a reason for voting no. The subsequent "Arrow Functions" RFC [4] by Bob and Levi in 2017 explicitly removed multi-statement bodies from the proposal, citing feedback from previous discussions. Bob confirmed in the discussion thread [5] that this was a deliberate design choice, because requiring "use" for most Closures "vastly improves readability and debuggability". Rasmus agreed [6] that automatic capture was acceptable in the new RFC specifically because single-expression closures "don't typically need a local scope at all". Finally, in 2019 Nikita wrote a new version of the RFC [7] which again left out multi-statement bodies. During the discussion [8] he considered adding them back in, but felt it would "add a number of complications" which should be addressed in a future RFC. Several people who had previously expressed strong concerns about automatic capture voted "Yes" to Nikita's RFC . At least some presumably did so precisely because multi-statement bodies were not included. [1] https://wiki.php.net/rfc/short_closures [2] https://externals.io/message/87958#87969 [3] https://externals.io/message/88394 [4] https://wiki.php.net/rfc/arrow_functions [5] https://externals.io/message/98045#98069 [6] https://externals.io/message/98045#98108 [7] https://wiki.php.net/rfc/arrow_functions_v2 [8] https://externals.io/message/104693#104738 Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] Add fetch_column method to mysqli
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 opinions. I also have doubts about the scope. Is the scope too limited? Should it involve a change to fetch_all as well? On the implementation part, I wonder if it could be optimized. The one I have written works but doesn't look like the most efficient way to do this. Kind Regards, Kamil Tekiela
[PHP-DEV] Proposal: add IntlDateTimePatternGenerator
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/icu4c/classicu_1_1DateTimePatternGenerator.html)
This allows more flexibility than the current $format argument of
IntlDateFormatter::format(), which takes either a few pre-defined constants or
a hard-coded format.
This functionality also has been requested in the past. (see
https://bugs.php.net/bug.php?id=70377)
For example, if an application requires a format that will always use the long
version of a year, but the short version of a month (eg. "MM/dd/" for
"en_US", or "dd.MM." for "de_DE"), one is out of luck.
IntlDateFormatter::SHORT will use the short year for "de_DE" ("dd.MM.YY"), and
IntlDateFormatter::MEDIUM will use the long version of a month for "en_US"
("MMM dd, ").
With IntlDateTimePatternGenerator::getBestPattern(), a skeleton can be provided
to generate the appropriate pattern for a given locale.
In the use-case given above, the skeleton "MMdd" will generate the desired
patterns for each locale, which can then be passed to
IntlDateFormatter::format().
Proposed Signature:
```
class IntlDateTimePatternGenerator
{
public function __construct(?string $locale = null) {}
public static function create(?string $locale = null):
?IntlDateTimePatternGenerator {}
public function getBestPattern(string $skeleton): string|false {}
}
```
Example use-case:
```
$date = new \DateTime();
$skeleton = "MMdd";
$dtpg = new \IntlDateTimePatternGenerator(); // uses default locale if not
specified
$format = $dtpg->getBestPattern($skeleton);
echo \IntlDateFormatter::formatObject($date, $format); // outputs "28.03.2020"
for "de_DE" locale
```
The proposed implementation can be found here:
https://github.com/php/php-src/pull/6771
I assume that this will require an RFC, in which case I request the karma to
create one. My wiki account is deltragon.
Regards,
Mel Dafert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2
> 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 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
>> perspective doesn't match the proposed RFC. The RFC is extending short
>> closure to support multiple statements and defining good semantics on how
>> developers will interpret fn, => and {} throughout the language.
>
> I think we have some sort of conundrum. I am not saying auto capture
> is not good semantics if that is what you are implying, I more than
> anyone would like consistency in the language but it is not a good
> language design to have two very similar features separated by a
> shorter keyword which implies totally different semantics. I don't
> find this a very intuitive way nor a good developer experience. I can
> understand that the connection of the `fn` keyword already having the
> meaning it has, 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 inherit the scope from which it was
> declared (usually the global scope)? What about methods declarations,
> do they import properties into the local scope? How does traits
> interact here, same as methods?
>
> This is why I think having the `fn` being an alias of `function`
> neutralizes the argument of what happens for exactly those reasonings
> above, this allows arrow functions to continue being auto capture
> without any keyword.
I am curious how requiring developers to learn that "=>" means auto-capture and
having developers question when they should choose "fn" instead of "function"
when the answer is "it does not matter" is a more intuitive and a better
developer experience than requiring developers to simply learn that "fn" means
auto-capture?
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2
>
> 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 inherit the scope from which it was
> declared (usually the global scope)? What about methods declarations,
> do they import properties into the local scope? How does traits
> interact here, same as methods?
>
I think I remember the 1st version of Larry's RFC proposing `public fn
classMethod(): bool => $this->myAttr;` as a class method which seems to
match what you're trying to say here, but that has been withdrawn and the
RFC no longer proposes the fn keyword for class methods or function
declarations, which is discussed under *Background* of RFC
https://wiki.php.net/rfc/auto-capture-closure. Larry and Nuno may correct
me if I'm wrong but as far as I understood, that change happened to address
exactly the points you're describing here: what does `public fn
classMethod(): bool` would capture? There's actually little to no reason to
do it. Larry's RFC still proposes a great improvement for
getters/setters/short methods and Nuno's RFC allows us to write code that
is naturally expected to work, such as `fn () => {...}`.
As for making `fn` an alias of `function` I believe that is already broken
because of 7.4 arrow functions. As you describe, that would be "an
exception" to PHP syntax, but more pressing it means that we would be
wasting the potential of 2 separate keywords having different goals. I
think it was Nikita that once said that we have a very limited budget on
what we can do/offer through programming syntax and throwing `fn` out would
be such a waste of that limited budget.
--
Marco Aurélio Deleu
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2
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 look like PHP can't make up it's mind, I feel that your perspective
> doesn't match the proposed RFC. The RFC is extending short closure to support
> multiple statements and defining good semantics on how developers will
> interpret fn, => and {} throughout the language.
I think we have some sort of conundrum. I am not saying auto capture
is not good semantics if that is what you are implying, I more than
anyone would like consistency in the language but it is not a good
language design to have two very similar features separated by a
shorter keyword which implies totally different semantics. I don't
find this a very intuitive way nor a good developer experience. I can
understand that the connection of the `fn` keyword already having the
meaning it has, 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 inherit the scope from which it was
declared (usually the global scope)? What about methods declarations,
do they import properties into the local scope? How does traits
interact here, same as methods?
This is why I think having the `fn` being an alias of `function`
neutralizes the argument of what happens for exactly those reasonings
above, this allows arrow functions to continue being auto capture
without any keyword. And again; adding an `auto` keyword is also not
an alien thing to Closures because we already have the `static`
keyword which acts as a feature flag, something which arrow functions
already support which also is a case that can easily mess up the order
of which objects are destructed in if you make a Closure that does not
interact with `$this` from an object context without declaring it as
`static`.
While I did not agree with this in the initial RFC that implemented
arrow functions, I do see its value and agree with it due to the
narrow scope of which arrow functions have, and therefore I think it
is fine to have the exception of making arrow functions behave this
way and would have voted as such had it come to my desk today.
And again, kindly stop top posting.
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and short functions take 2
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 change in
variables scope handling (auto-capturing). Note that in Javascript it is
a new syntax not just the keyword.
Looks like a counter-proposal could be this syntax:
$foo = function($a, $b) => {
$val = $a * $b;
return $val * c;
}
then whether it is `fn` or `function` keyword does not really matter.
Here it is `=>` that indicates the auto-capturing in the block on the
right side.
I don't know. Another approach might be something that makes mind to
think this is something different than a function. A completely new
keyword that makes the code block to auto-capture. E.g. `procedure` or
`macro`.
--
Aleksander Machniak
Kolab Groupware Developer[https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]
PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2
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
perspective doesn't match the proposed RFC. The RFC is extending short
closure to support multiple statements and defining good semantics on how
developers will interpret fn, => and {} throughout the language.
On Sun, Mar 28, 2021, 12:21 Kalle Sommer Nielsen wrote:
> 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, concise, consistent and simple.
>
> (First off, please read our mailing lists rules[1] and do not top post)
>
> If we go by the inconsistent behavior then by that definition short
> arrow functions are inconsistent with the rest of PHP as there is no
> auto capture elsewhere.
>
> This is not short arrow functions being expanded to support multi
> lines, but rather the other way around, with multi line closures being
> able to support auto capture which is identified by the `fn` keyword
> and because of that, I would much rather have a `fn` be an alias of
> `function` and then having the ability to put a keyword to declare
> that you wish to use auto capture (which is consistent with the
> exisiting design of PHP where you have to declare globals with the
> `global` keyword or explicit imports to closures with the `use`
> statement (which used to be done by the `lexical` keyword similarily
> to the `global` keyword in early PHP 5.3.0 development) -- if you are
> interested in this philosophy you can try lookup videos from some of
> Rasmus' presentations where he explains his dislike with globals
> coming from C). To back this up further, we also have the `static`
> keyword which acts as a feature flag so it is not unnatural, the
> naming of the keyword `auto` sure, but that is another discussion.
>
> [1]
> https://git.php.net/?p=php-src.git;a=blob_plain;f=docs/mailinglist-rules.md;hb=HEAD
>
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2
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 is less of an issue with capture by value, but can still mean resources not being freed, e.g. a large array of data not being freed from memory, or an object destructor not executing when expected. This is more likely in PHP than many other languages, because there is no requirement, or even an option, to explicitly declare a local variable in the closure. It's not a new problem, but since single-expression closures are unlikely to use many local variables, it's probably not one that's been given lots of thought. I do think it is great that you are thinking about how this can negatively effect memory or performance (and things like destructors) and if things can be improved. But do the same problems not exist when binding the current class to an anonymous function - whenever an anonymous function is declared in a class (no matter if by function or fn) the whole class is bound to that function, if you don't explicitely use "static function". That binding can encompass many variables and other classes etc., which is common nowadays with dependency injection, yet I have not heard much about problems surrounding this. Binding the variables from the current scope seems like a smaller impact compared to already binding the whole class and all its dependencies. I would welcome any way of automatically capturing all local variables, as this would be a big "quality-of-life" improvement similar to constructor property promotion, to avoid a lot of boilerplate code. I would not use it that much, but when I use it, it would be a big improvement. Using "fn" for this seems consistent to me, and I don't think people would always use it just because it is shorter - and IDEs and static analyzers could detect and discourage use of "fn" if "function" would be sufficient. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2
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, concise, consistent and simple. (First off, please read our mailing lists rules[1] and do not top post) If we go by the inconsistent behavior then by that definition short arrow functions are inconsistent with the rest of PHP as there is no auto capture elsewhere. This is not short arrow functions being expanded to support multi lines, but rather the other way around, with multi line closures being able to support auto capture which is identified by the `fn` keyword and because of that, I would much rather have a `fn` be an alias of `function` and then having the ability to put a keyword to declare that you wish to use auto capture (which is consistent with the exisiting design of PHP where you have to declare globals with the `global` keyword or explicit imports to closures with the `use` statement (which used to be done by the `lexical` keyword similarily to the `global` keyword in early PHP 5.3.0 development) -- if you are interested in this philosophy you can try lookup videos from some of Rasmus' presentations where he explains his dislike with globals coming from C). To back this up further, we also have the `static` keyword which acts as a feature flag so it is not unnatural, the naming of the keyword `auto` sure, but that is another discussion. [1] https://git.php.net/?p=php-src.git;a=blob_plain;f=docs/mailinglist-rules.md;hb=HEAD regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2
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 Kalle Sommer Nielsen wrote:
> Hi Rowan
>
> Den lør. 27. mar. 2021 kl. 18.05 skrev Rowan Tommins <
> rowan.coll...@gmail.com>:
> > 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();
> > // ...
> > $fn = fn() {
> > $results = []; // coincidentally the same name, immediately
> > assigned its own value
> > // ...
> > }
> > unset($results); // does not free the array, because $fn has captured
> > the value
>
> I too am very concerned about this exact senario because it very
> easily overlooked. While I understand the appeal of having very short
> closures, I do think that such behavior needs to be explicit and would
> much rather prefer something like this:
>
> - Make the `fn` keyword an alias of the `function` keyword
> - Add a new `auto` (or similar) keyword for explicit auto capture
>
> Something like this:
> ```php
> return function () use ($v1, $v2, $v3, $v4) {
> /* ... */
> };
> ```
>
> Would then be abled to be turned into:
> ```php
> return auto fn () {
> /* ... */
> };
> ```
>
> That way it is very clear that the closure is intending on auto
> capturing at this point, at the same time it also allows people like
> me who prefers the `function` keyword to write.
>
> I personally don't think adding those 5 extra characters here for
> explicitity is bad, I would like explicitly over implicitit, I can see
> how many would simply just write `fn` without knowing there is a very
> vitual difference (similar to `static` closures is rare if you don't
> intend on binding `$this`).
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2
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();
> // ...
> $fn = fn() {
> $results = []; // coincidentally the same name, immediately
> assigned its own value
> // ...
> }
> unset($results); // does not free the array, because $fn has captured
> the value
I too am very concerned about this exact senario because it very
easily overlooked. While I understand the appeal of having very short
closures, I do think that such behavior needs to be explicit and would
much rather prefer something like this:
- Make the `fn` keyword an alias of the `function` keyword
- Add a new `auto` (or similar) keyword for explicit auto capture
Something like this:
```php
return function () use ($v1, $v2, $v3, $v4) {
/* ... */
};
```
Would then be abled to be turned into:
```php
return auto fn () {
/* ... */
};
```
That way it is very clear that the closure is intending on auto
capturing at this point, at the same time it also allows people like
me who prefers the `function` keyword to write.
I personally don't think adding those 5 extra characters here for
explicitity is bad, I would like explicitly over implicitit, I can see
how many would simply just write `fn` without knowing there is a very
vitual difference (similar to `static` closures is rare if you don't
intend on binding `$this`).
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] debug_backtrace_depth(int $limit=0): int
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 temporary debug statements > 2. Checking for potential infinite recursion or investigating reproducible > reports of infinite recursion > 3. Checking if code is likely to hit stack frame limits when run in > environments using extensions such as Xdebug > (https://xdebug.org/docs/all_settings#max_nesting_level , which also > checks for potential infinite recursion) > (note that Xdebug is a debugger - running php under xdebug is > significantly slower than without Xdebug) > > It is currently possible to compute the depth through > `count(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, $limit=0))`, > but this is verbose, inefficient, and harder to read compared to returning > the depth directly. > > Thoughts? > > Thanks, > - Tyson There hasn't been much discussion on this one, probably because the functionality and use cases are so specific. I'm not really convinced by your examples. For the purpose of printing debug logs, using an engine-provided depth is non-ideal, because any intermediate helper functions will count towards the depth. Tracking your own depth will result in a more meaningful/predictable output. For tracking down infinite recursion, isn't this what the xdebug recursion limit is for? You'll directly get your recursive stack trace, which should make it obvious where the infinite recursion occurs. Using debug_backtrace_depth() for this purpose means that you actually already need to know where you are infinitely recursing in order to place the guard. If you want to find places where your code would hit the xdebug recursion limit, then why not run it under xdebug and find out, rather than trying to simulate the same behavior manually? That again requires that you actually place relevant guards in the first place, which makes this another chicken and egg problem. Regards, Nikita
