[PHP-DEV] Re: Potential RFC around PDO

2021-02-17 Thread Mark Randall

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

2021-02-17 Thread Mark Randall

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?

2021-02-17 Thread David Rodrigues
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

2021-02-17 Thread Daniel Beardsley
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?

2021-02-17 Thread Nikita Popov
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?

2021-02-17 Thread David Rodrigues
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

2021-02-17 Thread Ben Ramsey
> 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

2021-02-17 Thread Rowan Tommins

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

2021-02-17 Thread Ben Ramsey
> 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

2021-02-17 Thread Chase Peeler
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

2021-02-17 Thread Ben Ramsey
> 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

2021-02-17 Thread Chase Peeler
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

2021-02-17 Thread Rowan Tommins

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

2021-02-17 Thread Pierre

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

2021-02-17 Thread Benjamin Morel
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

2021-02-17 Thread Larry Garfield
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