[PHP-DEV] Re: Potential RFC around PDO
On 18/02/2021 03:37, Mark Randall wrote: Long ago, PHP had a similar feature called Magic Quotes. My apologies, I had only that top paragraph visible in my preview and responded to entirely the wrong part of your post :-( -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Potential RFC around PDO
On 18/02/2021 00:57, Daniel Beardsley wrote: At iFixit we use a forked version of php with a small change to allow automatically html-escaping echoed strings: https://github.com/iFixit/php-src/commit/cb6eb5c35a07c843e5b357884186d77e3a1a2981 Long ago, PHP had a similar feature called Magic Quotes. It is now universally considered to be among the worst and most damaging features that PHP ever introduced. There is no apetite to reintroduce such a thing. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] preg_replace(string, null) is allowed?
Thanks! There is a reason why it is not supported anymore? There is a difference in output or performance, maybe? Atenciosamente, David Rodrigues Em qua., 17 de fev. de 2021 às 17:37, Nikita Popov escreveu: > On Wed, Feb 17, 2021 at 9:28 PM David Rodrigues > wrote: > >> Hello! >> >> I am in doubt if passing null as the second argument to preg_replace() is >> valid. Actually, it works as expected. >> >> https://3v4l.org/0TITS >> >> But doc only accepts array|string. >> >> I am asking for it because PhpStorm will not accept it. So if it is valid, >> I will do a PR to PS stubs. >> > > On PHP 8.1.0-dev your example prints: > > Deprecated: preg_replace(): Passing null to parameter #2 > ($replacement) of type array|string is deprecated in %s on line 3 > > Under strict_types=1 it already throws. > > So no, it is not valid. > > Regards, > Nikita > >
[PHP-DEV] Potential RFC around PDO
wiki username: danielbeardsley === Background I was told to introduce myself. I've been in software development for more than 20 years and have been working with php for 10 or so of that. I've only had a little contact with this group, but I've got at least one past pull merged on the php-src repo: https://github.com/php/php-src/pull/271. At iFixit we use a forked version of php with a small change to allow automatically html-escaping echoed strings: https://github.com/iFixit/php-src/commit/cb6eb5c35a07c843e5b357884186d77e3a1a2981 . It's not something this list would be interested in as it's rather special-purpose, but I'm mentioning it to show I'm somewhat familiar with the php build system. === Why I'm emailing now: I've opened a pull request on php-src: https://github.com/php/php-src/pull/6677 and I've been advised to make an RFC. The first step is emailing! I'd like to propose adding a function to the mysql pdo driver (in the same way postgres and sqlite have) to extract the count of warnings from the last executed statement. See the pull request linked above for a more thorough description. Should I make an RFC out of this? Thanks for your time! Daniel Beardsley
Re: [PHP-DEV] preg_replace(string, null) is allowed?
On Wed, Feb 17, 2021 at 9:28 PM David Rodrigues wrote: > Hello! > > I am in doubt if passing null as the second argument to preg_replace() is > valid. Actually, it works as expected. > > https://3v4l.org/0TITS > > But doc only accepts array|string. > > I am asking for it because PhpStorm will not accept it. So if it is valid, > I will do a PR to PS stubs. > On PHP 8.1.0-dev your example prints: Deprecated: preg_replace(): Passing null to parameter #2 ($replacement) of type array|string is deprecated in %s on line 3 Under strict_types=1 it already throws. So no, it is not valid. Regards, Nikita
[PHP-DEV] preg_replace(string, null) is allowed?
Hello! I am in doubt if passing null as the second argument to preg_replace() is valid. Actually, it works as expected. https://3v4l.org/0TITS But doc only accepts array|string. I am asking for it because PhpStorm will not accept it. So if it is valid, I will do a PR to PS stubs. Thanks! Atenciosamente, David Rodrigues
Re: [PHP-DEV] [VOTE] Enumerations
> On Feb 17, 2021, at 12:08, Rowan Tommins wrote: > > On 17/02/2021 17:51, Ben Ramsey wrote: >>> On Feb 17, 2021, at 11:48, Chase Peeler wrote: >>> >>> If that were to not pass, though, it seems supporting enum cases as keys >>> would be worth exploring. Fully support allowing all objects as keys though. >> >> Others, please correct me if I’m wrong, but I believe each enum case is >> already an object. > > > I think what Chase meant was that if we don't want to allow *all* objects as > keys, we could allow *a specific subset*, namely Enum cases. > > The implementation would be similar, but deliberately limiting the scope > might avoid some undesirable edge cases and side effects. Sorry. When I read “were to not pass,” my brain missed the “not” part. :-) Cheers, Ben signature.asc Description: Message signed with OpenPGP
Re: [PHP-DEV] [VOTE] Enumerations
On 17/02/2021 17:51, Ben Ramsey wrote: On Feb 17, 2021, at 11:48, Chase Peeler wrote: If that were to not pass, though, it seems supporting enum cases as keys would be worth exploring. Fully support allowing all objects as keys though. Others, please correct me if I’m wrong, but I believe each enum case is already an object. I think what Chase meant was that if we don't want to allow *all* objects as keys, we could allow *a specific subset*, namely Enum cases. The implementation would be similar, but deliberately limiting the scope might avoid some undesirable edge cases and side effects. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Enumerations
> On Feb 17, 2021, at 11:48, Chase Peeler wrote: > > If that were to not pass, though, it seems supporting enum cases as keys > would be worth exploring. Fully support allowing all objects as keys though. Others, please correct me if I’m wrong, but I believe each enum case is already an object. Cheers, Ben signature.asc Description: Message signed with OpenPGP
Re: [PHP-DEV] [VOTE] Enumerations
On Wed, Feb 17, 2021 at 12:41 PM Ben Ramsey wrote: > > On Feb 17, 2021, at 09:26, Chase Peeler wrote: > > > > On Wed, Feb 17, 2021 at 10:09 AM Rowan Tommins > > wrote: > > > >> On 17/02/2021 14:30, Larry Garfield wrote: > >>> The Enum RFC has been approved. > >> > >> > >> Thank you and Ilija so much for putting in the effort to make such a > >> carefully thought-through proposal, and I'm really looking forward to > >> being able to use it. > >> > >> I realise not everyone agrees with the approach, but am hopeful that it > >> can be expanded on in future proposals to add a lot of power to the > >> language. > >> > >> > > Glad to see this passed. I definitely would have voted for it if I had a > > vote. The only thing I wish had been included was the ability to use them > > as array keys, but definitely don't think the lack of that would be a > > reason to vote against it - especially since the possibility is still > open > > in the future and adding it wouldn't cause any BC issues. > > > There’s an RFC for that. ;-) > > https://wiki.php.net/rfc/object_keys_in_arrays > > Cheers, > Ben > > If that were to not pass, though, it seems supporting enum cases as keys would be worth exploring. Fully support allowing all objects as keys though. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [VOTE] Enumerations
> On Feb 17, 2021, at 09:26, Chase Peeler wrote: > > On Wed, Feb 17, 2021 at 10:09 AM Rowan Tommins > wrote: > >> On 17/02/2021 14:30, Larry Garfield wrote: >>> The Enum RFC has been approved. >> >> >> Thank you and Ilija so much for putting in the effort to make such a >> carefully thought-through proposal, and I'm really looking forward to >> being able to use it. >> >> I realise not everyone agrees with the approach, but am hopeful that it >> can be expanded on in future proposals to add a lot of power to the >> language. >> >> > Glad to see this passed. I definitely would have voted for it if I had a > vote. The only thing I wish had been included was the ability to use them > as array keys, but definitely don't think the lack of that would be a > reason to vote against it - especially since the possibility is still open > in the future and adding it wouldn't cause any BC issues. There’s an RFC for that. ;-) https://wiki.php.net/rfc/object_keys_in_arrays Cheers, Ben signature.asc Description: Message signed with OpenPGP
Re: [PHP-DEV] Re: [VOTE] Enumerations
On Wed, Feb 17, 2021 at 10:09 AM Rowan Tommins wrote: > On 17/02/2021 14:30, Larry Garfield wrote: > > The Enum RFC has been approved. > > > Thank you and Ilija so much for putting in the effort to make such a > carefully thought-through proposal, and I'm really looking forward to > being able to use it. > > I realise not everyone agrees with the approach, but am hopeful that it > can be expanded on in future proposals to add a lot of power to the > language. > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > Glad to see this passed. I definitely would have voted for it if I had a vote. The only thing I wish had been included was the ability to use them as array keys, but definitely don't think the lack of that would be a reason to vote against it - especially since the possibility is still open in the future and adding it wouldn't cause any BC issues. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Re: [VOTE] Enumerations
On 17/02/2021 14:30, Larry Garfield wrote: The Enum RFC has been approved. Thank you and Ilija so much for putting in the effort to make such a carefully thought-through proposal, and I'm really looking forward to being able to use it. I realise not everyone agrees with the approach, but am hopeful that it can be expanded on in future proposals to add a lot of power to the language. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] Enumerations
Le 17/02/2021 à 15:30, Larry Garfield a écrit : The Enum vote has now closed. Final results: For: 44 Against: 7 Approval rate: 86% The Enum RFC has been approved. Ilija is still fixing up some bugs and edge cases in the code itself but it should be merged soon. Thank you to everyone for your feedback, support, and votes over the past few weeks! I would enumerate you all individually, but there's a lot of you and it would take up a lot of memory... :-) --Larry Garfield That's great ! Thank you very much for all this work ! Regards, -- Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] Enumerations
Congratulations and thank you Larry and Ilija, this will be a great addition to PHP! — Benjamin On Wed, 17 Feb 2021 at 15:31, Larry Garfield wrote: > On Wed, Feb 3, 2021, at 11:28 AM, Larry Garfield wrote: > > The vote on the Enumerations RFC is hereby opened. It will run until > > 17 February 2021. > > > > https://wiki.php.net/rfc/enumerations > > > > Vote now, or forever hold your memory allocations. > > > The Enum vote has now closed. Final results: > > For: 44 > Against: 7 > Approval rate: 86% > > The Enum RFC has been approved. Ilija is still fixing up some bugs and > edge cases in the code itself but it should be merged soon. > > Thank you to everyone for your feedback, support, and votes over the past > few weeks! I would enumerate you all individually, but there's a lot of > you and it would take up a lot of memory... :-) > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
[PHP-DEV] Re: [VOTE] Enumerations
On Wed, Feb 3, 2021, at 11:28 AM, Larry Garfield wrote: > The vote on the Enumerations RFC is hereby opened. It will run until > 17 February 2021. > > https://wiki.php.net/rfc/enumerations > > Vote now, or forever hold your memory allocations. The Enum vote has now closed. Final results: For: 44 Against: 7 Approval rate: 86% The Enum RFC has been approved. Ilija is still fixing up some bugs and edge cases in the code itself but it should be merged soon. Thank you to everyone for your feedback, support, and votes over the past few weeks! I would enumerate you all individually, but there's a lot of you and it would take up a lot of memory... :-) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php