Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1

Hi! > date_sunrise() and date_sunset() Do we have any information on usage? I am generally not a fan of deprecating functions that work - even if they are odd and have quirky APIs - but if the usage is essentially zero than it might be ok. > key(), current(), next(), prev(), and reset() on

Re: [PHP-DEV] Re: Release Managers for PHP 8.1

If they were open to it, it might be advantageous for veterans to make some YouTube videos as they're going through the processes. That way infinite people can watch it actually being done for real and learn the processes well in advance without having to explain to each person one by one many

Re: [PHP-DEV] Re: Release Managers for PHP 8.1

On Mon, Mar 22, 2021 at 3:34 PM Levi Morrison wrote: > > We've got two "newbie" volunteers already, but we should ideally have a > > veteral available. So I'm especially calling for some old timers to step > > up and teach the kids some new tricks. > > > By the way, it seems like we have newbies

Re: [PHP-DEV] Re: Release Managers for PHP 8.1

On Mon, Mar 22, 2021 at 5:20 PM Harm Smits wrote: > I'd love to put my hat in the ring, although it will be my first time, but > like stated, there are no spots > available anymore. However, I wouldn't mind observing the process to at > least get some experience > for being a release manager in

Re: [PHP-DEV] Re: Release Managers for PHP 8.1

To add to Levi's comment, I'd love to put my hat in the ring, although it will be my first time, but like stated, there are no spots available anymore. However, I wouldn't mind observing the process to at least get some experience for being a release manager in the future. Please let me know

Re: [PHP-DEV] Re: Release Managers for PHP 8.1

On Mon, Mar 22, 2021 at 2:24 PM Sara Golemon wrote: > > On Mon, Mar 1, 2021 at 11:09 AM Sara Golemon wrote: > > > This is your early, advance warning that RM selection for the PHP 8.1 > > branch will be coming up in April. Please start thinking about whether or > > not you would like to put

[PHP-DEV] Re: Release Managers for PHP 8.1

On Mon, Mar 1, 2021 at 11:09 AM Sara Golemon wrote: > This is your early, advance warning that RM selection for the PHP 8.1 > branch will be coming up in April. Please start thinking about whether or > not you would like to put your hat in the ring. Feel free to volunteer now, > or any time

Re: [PHP-DEV] [VOTE] Fibers

> > >> I hope others would > >> play with it more as well if we had more time. Any objections? > > > > Yes, I object. > > > > You've been around PHP internals long enough to see the drama has > > occurred on other RFCs where people have been > > cajoled/pressured/threatened to either suspend votes

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

On Mon, Mar 22, 2021 at 10:04 AM Aleksander Machniak wrote: > $str = "グーグル谷歌中信фδοκιμήóźdźрöß"; > > $this->assertSame($str, utf8_decode(utf8_encode($str))); > > Woah. Yeah. No. Don't do that. Doing that is what's wrong with utf8_en/decode(). Doing that convinces me that Rowan is right

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

On 22/03/2021 18:18, Chase Peeler wrote: Even if it is by accident, removing or changing the behavior of the function is guaranteed to make something that currently works (by skill or by luck) and risk it no longer working. This is absolutely true. However, at some point you have to draw

Re: [PHP-DEV] [VOTE] Fibers

> On Mar 22, 2021, at 13:21, Dan Ackroyd wrote: > > On Fri, 19 Mar 2021 at 20:53, Levi Morrison via internals > wrote: >> I hope others would >> play with it more as well if we had more time. Any objections? > > Yes, I object. > > You've been around PHP internals long enough to see the drama

Re: [PHP-DEV] [VOTE] Fibers

On Mon, Mar 22, 2021 at 2:22 PM Dan Ackroyd wrote: > On Fri, 19 Mar 2021 at 20:53, Levi Morrison via internals > wrote: > > I hope others would > > play with it more as well if we had more time. Any objections? > > Yes, I object. > > You've been around PHP internals long enough to see the drama

Re: [PHP-DEV] [VOTE] Fibers

On Fri, 19 Mar 2021 at 20:53, Levi Morrison via internals wrote: > I hope others would > play with it more as well if we had more time. Any objections? Yes, I object. You've been around PHP internals long enough to see the drama has occurred on other RFCs where people have been

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

On Mon, Mar 22, 2021 at 1:22 PM Rowan Tommins wrote: > On 22/03/2021 16:52, Aleksander Machniak wrote: > > On 22.03.2021 16:41, Rowan Tommins wrote: > >> That code will never do anything useful. > > I already proved it is useful, regardless of it's name/intention. > > > You have proven no such

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

On 22/03/2021 17:38, Alexandru Pătrănescu wrote: As Rowan mentioned, base64_encode would have worked. But that means one quarter of the available max column space would be lost as a downside. Depending on the data, abusing Latin1-to-UTF8 translation can easily result in a longer string than

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

On Mon, Mar 22, 2021 at 7:24 PM Alexandru Pătrănescu wrote: > > There could have been better ways to fix it. > json_encode / json_decode would have worked just the same. > > Nope, strings in a json object must be UTF-8. As Rowan mentioned, base64_encode would have worked. But that means one

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1

On 22/03/2021 17:27, Nikita Popov wrote: Sure. Rowan, if you would like to add these functions to this RFC, please feel free to just edit it directly. Otherwise, having a separate RFC just for them is also fine. Given the situation is complex, and at least somewhat controversial, I plan

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1

On Mon, Mar 22, 2021 at 3:58 PM Ben Ramsey wrote: > > On Mar 22, 2021, at 04:24, Nikita Popov wrote: > > > > Hi internals, > > > > It's time for another deprecation RFC: > > https://wiki.php.net/rfc/deprecations_php_8_1 > > > > This is a collection of minor deprecations that various people have

Re: [PHP-DEV] [VOTE] Fibers

On Mon, 22 Mar 2021 at 18:23, Guilliam Xavier wrote: > > On Mon, Mar 22, 2021 at 5:23 PM G. P. B. wrote: > > > > > The thing is that by my recollections votes have already been extended. > > Mostly when there has been issues with the mailing list, or some outside > > event. > > > > Moreso, I

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

On Mon, Mar 22, 2021 at 6:52 PM Aleksander Machniak wrote: > On 22.03.2021 16:41, Rowan Tommins wrote: > > That code will never do anything useful. > > I already proved it is useful, regardless of it's name/intention. > > This is old code, not even mine, so maybe when it's been written the PHP >

Re: [PHP-DEV] [VOTE] Fibers

On Mon, Mar 22, 2021 at 5:23 PM G. P. B. wrote: > > The thing is that by my recollections votes have already been extended. > Mostly when there has been issues with the mailing list, or some outside > event. > > Moreso, I don't think extending a vote will in most cases result in the > outcome >

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

On 22/03/2021 16:52, Aleksander Machniak wrote: On 22.03.2021 16:41, Rowan Tommins wrote: That code will never do anything useful. I already proved it is useful, regardless of it's name/intention. You have proven no such thing. If that function is saving you from errors, it is completely

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1

Den 2021-03-22 kl. 15:58, skrev Ben Ramsey: On Mar 22, 2021, at 04:24, Nikita Popov wrote: Hi internals, It's time for another deprecation RFC: https://wiki.php.net/rfc/deprecations_php_8_1 This is a collection of minor deprecations that various people have put together over the last ~2

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

> On Mar 22, 2021, at 5:45 AM, Nikita Popov wrote: > > On Fri, Mar 19, 2021 at 7:28 PM Mike Schinkel > wrote: > > On Feb 25, 2021, at 3:26 PM, Nikita Popov > > wrote: > > > > Hi internals, > > > > The question of namespaces in the

[PHP-DEV] Re: RFC: PDO MySQL get warning count

On 26.02.2021 at 17:45, Daniel Beardsley wrote: > I've gotten very little feedback on the "should I make an RFC about this?" > question, so I went ahead and made an RFC: > https://wiki.php.net/rfc/pdo-mysql-get-warning-count > > This is about a feature in an open pull request: >

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

On 22.03.2021 16:41, Rowan Tommins wrote: > That code will never do anything useful. I already proved it is useful, regardless of it's name/intention. This is old code, not even mine, so maybe when it's been written the PHP documentation wasn't that clear about the function(s) intention. Or the

Re: [PHP-DEV] [VOTE] Fibers

On Mon, 22 Mar 2021 at 16:20, G. P. B. wrote: > On Mon, 22 Mar 2021 at 16:01, Guilliam Xavier > wrote: > >> On Mon, Mar 22, 2021 at 4:38 PM Levi Morrison < >> levi.morri...@datadoghq.com> >> wrote: >> >> > On Mon, Mar 22, 2021 at 9:13 AM Guilliam Xavier >> > wrote: >> > > >> > > On Sat, Mar

Re: [PHP-DEV] [VOTE] Fibers

On Mon, 22 Mar 2021 at 16:01, Guilliam Xavier wrote: > On Mon, Mar 22, 2021 at 4:38 PM Levi Morrison > > wrote: > > > On Mon, Mar 22, 2021 at 9:13 AM Guilliam Xavier > > wrote: > > > > > > On Sat, Mar 20, 2021 at 3:06 PM Aaron Piotrowski > > wrote: > > >> > > >> > > >> > On Mar 19, 2021, at

Re: [PHP-DEV] [VOTE] Fibers

> > I also cannot find anything in the rules that allows for the author > canceling an ongoing vote, but I believe we’ve done that in the past. > Maybe this mention in https://wiki.php.net/rfc/howto (not sure it's authoritative though)? > 7. Based on the result of the votes and the discussion

Re: [PHP-DEV] [VOTE] Fibers

On Mon, Mar 22, 2021 at 4:38 PM Levi Morrison wrote: > On Mon, Mar 22, 2021 at 9:13 AM Guilliam Xavier > wrote: > > > > On Sat, Mar 20, 2021 at 3:06 PM Aaron Piotrowski > wrote: > >> > >> > >> > On Mar 19, 2021, at 5:47 PM, Levi Morrison < > levi.morri...@datadoghq.com> wrote: > >> > > >> > On

Re: [PHP-DEV] [VOTE] Fibers

On Mon, Mar 22, 2021 at 9:55 AM Rowan Tommins wrote: > > On 22/03/2021 15:38, Levi Morrison via internals wrote: > > We should dig through the history, because the line before that is in > > conflict: > > > >> Votes should be open for two weeks at minimum, at the authors discretion > >> this

Re: [PHP-DEV] [VOTE] Fibers

> On Mar 22, 2021, at 10:38, Levi Morrison via internals > wrote: > > On Mon, Mar 22, 2021 at 9:13 AM Guilliam Xavier > wrote: >> >> On Sat, Mar 20, 2021 at 3:06 PM Aaron Piotrowski wrote: >>> >>> On Mar 19, 2021, at 5:47 PM, Levi Morrison wrote: On Fri, Mar 19, 2021

Re: [PHP-DEV] [VOTE] Fibers

On 22/03/2021 15:38, Levi Morrison via internals wrote: We should dig through the history, because the line before that is in conflict: Votes should be open for two weeks at minimum, at the authors discretion this may be extended, for example during holiday periods. A valid voting period must

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

On 22/03/2021 15:04, Aleksander Machniak wrote: I'm using utf8_encode()/utf8_decode() to make input string safe to be stored in DB, and back. In most cases the input is utf-8, but it occasionally may contain "broken characters". That is not what this function does, at all. The fact that its

Re: [PHP-DEV] [VOTE] Fibers

On Mon, Mar 22, 2021 at 9:13 AM Guilliam Xavier wrote: > > On Sat, Mar 20, 2021 at 3:06 PM Aaron Piotrowski wrote: >> >> >> > On Mar 19, 2021, at 5:47 PM, Levi Morrison >> > wrote: >> > >> > On Fri, Mar 19, 2021 at 3:54 PM Niklas Keller > > > wrote: >> >> >> >> Hey

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

> > I'm using utf8_encode()/utf8_decode() to make input string safe to be > stored in DB, and back. In most cases the input is utf-8, but it > occasionally may contain "broken characters". > What exactly do you mean by making the input string safe? If I understand correctly

Re: [PHP-DEV] [VOTE] Fibers

On Sat, Mar 20, 2021 at 3:06 PM Aaron Piotrowski wrote: > > > On Mar 19, 2021, at 5:47 PM, Levi Morrison > wrote: > > > > On Fri, Mar 19, 2021 at 3:54 PM Niklas Keller m...@kelunik.com>> wrote: > >> > >> Hey Levi, > >> > >>> On Mon, Mar 8, 2021 at 12:40 PM Aaron Piotrowski > wrote: > >

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

On 22.03.2021 15:30, Rowan Tommins wrote: > - Make utf8_decode() throw errors for unrepresentable characters. I'm not sure I understand this, but it sounds like it would be a BC break for my case. I'm using utf8_encode()/utf8_decode() to make input string safe to be stored in DB, and back. In

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1

> On Mar 22, 2021, at 04:24, Nikita Popov wrote: > > Hi internals, > > It's time for another deprecation RFC: > https://wiki.php.net/rfc/deprecations_php_8_1 > > This is a collection of minor deprecations that various people have put > together over the last ~2 years. This RFC was formerly

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

On 22/03/2021 13:18, Nicolas Grekas wrote: Shameless plug: the polyfill exists, without any dependency, see https://github.com/symfony/polyfill-php72/blob/main/Php72.php Ah, thanks for sharing that. I realised while trying to

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

On 22/03/2021 13:10, Sara Golemon wrote: > * People who just want to replace calls to utf8_decode won't want to go > through every call and make it exception safe. > Then they shouldn't use these replacements, it's not for them. It's for people using iso-8859-1. This is a non-sequitur.

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

Den 2021-03-22 kl. 14:10, skrev Sara Golemon: On Mon, Mar 22, 2021 at 5:24 AM Rowan Tommins wrote: I'm strongly against any concept of "indefinite deprecation". I consider any deprecation notice a commitment to remove the feature in the future, even if a specific timeline for that removal is

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

Le lun. 22 mars 2021 à 14:14, Sara Golemon a écrit : > On Mon, Mar 22, 2021 at 6:12 AM Rowan Tommins > wrote: > > I realise you can't speak for anyone else, but as a point of interest, > > would you be OK with a polyfill having a requirement on ext/mbstring or > > ext/iconv, or would you have a

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

On Mon, Mar 22, 2021 at 6:12 AM Rowan Tommins wrote: > I realise you can't speak for anyone else, but as a point of interest, > would you be OK with a polyfill having a requirement on ext/mbstring or > ext/iconv, or would you have a strong preference for a replacement built > into the core (i.e.

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

On Mon, Mar 22, 2021 at 5:24 AM Rowan Tommins wrote: > I'm strongly against any concept of "indefinite deprecation". I consider > any deprecation notice a commitment to remove the feature in the future, > even if a specific timeline for that removal is not given. > I don't feel strongly about

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

Den 2021-03-22 kl. 12:12, skrev Rowan Tommins: Hi Björn, On 22/03/2021 10:28, Björn Larsson wrote: In our case we use the utf8_decode functions to convert from UTF8 in the client to ISO-8859-1 on the server, since the site is encoded in latin1. Our usage of that function is working

Re: [PHP-DEV] [RFC] [Discussion] Adding return types to internal methods

> > I've updated the RFC with the following things: > - The proposed error level is now E_DEPRECATED instead of E_STRICT > - I added a new section for exposing the behavior to userland (this is a > separate vote) > To build on your approach and mixing it with the need we discussed for userland, I

Re: [PHP-DEV] [RFC] [Discussion] Adding return types to internal methods

Hi, I've updated the RFC with the following things: - The proposed error level is now E_DEPRECATED instead of E_STRICT - I added a new section for exposing the behavior to userland (this is a separate vote) As the 2 weeks of discussion has already passed, I'd like to start the vote in the near

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

Hi Björn, On 22/03/2021 10:28, Björn Larsson wrote: In our case we use the utf8_decode functions to convert from UTF8 in the client to ISO-8859-1 on the server, since the site is encoded in latin1. Our usage of that function is working flawlessly, so for us it's super important to have a clear

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

Den 2021-03-21 kl. 22:39, skrev Rowan Tommins: On 21/03/2021 21:00, Max Semenik wrote: Just a quick reminder that it's possible to compile PHP without mbstring and intl, which means that some hosts will provide PHP without these extensions, and some packagers make them available as separate

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

On 22/03/2021 01:15, Sara Golemon wrote: My preference is for a deprecation notice (but not necessarily removal ever -- We can argue that part a little). I'm strongly against any concept of "indefinite deprecation". I consider any deprecation notice a commitment to remove the feature in the

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

On Fri, Mar 19, 2021 at 7:28 PM Mike Schinkel wrote: > > On Feb 25, 2021, at 3:26 PM, Nikita Popov wrote: > > > > Hi internals, > > > > The question of namespaces in the stdlib has been coming up a lot > recently, > > so I'd like to present my own stab at resolving this question: > > > >

Re: [PHP-DEV] [RFC] [VOTE] mysqli bind in execute

On Tue, Mar 9, 2021 at 12:13 AM Kamil Tekiela wrote: > Hi Internals, > > I have opened voting on https://wiki.php.net/rfc/mysqli_bind_in_execute > Voting ends on 27th March > A minor BC break is not mentioned in the RFC: Classes extending mysqli_stmt::execute() will be required to specify the

[PHP-DEV] [RFC] Deprecations for PHP 8.1

Hi internals, It's time for another deprecation RFC: https://wiki.php.net/rfc/deprecations_php_8_1 This is a collection of minor deprecations that various people have put together over the last ~2 years. This RFC was formerly targeted at PHP 8.0, but was delayed to PHP 8.1 to reduce the amount

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

i would prefer to soft-deprecate them like we did with the mysql_ api, where they do not generate E_DEPRECATED for quite some time, but the documentation say "this function is deprecated, instead use mb_convert_encoding ( $str , "UTF-8", "ISO-8859-1" ); or iconv("ISO-8859-1","UTF-8", $str)" and..