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

[Stanislav Malyshev]

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 objects

I'd be happier if those worked with iterators. Except for prev() which I 
don't think many people need.


> mb_check_encoding() without argument

No objection.

> get_class(), get_parent_class() and get_called_class() without argument

I'm not sure why. I mean if we want to make them return the same as 
self::class etc. - up to the point of actually compiling them as such - 
no problem, but I don't see why they need to be deprecated. And I 
vaguely remember seeing get_class() at least a bunch of times in old 
code, when ::class didn't even exist. I don't see a good reason why that 
code should be broken.


> FILE_BINARY and FILE_TEXT constants

No objection.

> t fopen mode

I'm afraid there's - despite the warning - a bunch of code for Windows 
that relies on "t" and I don't think we should be breaking it. Is there 
a good reason to drop this mode?


> Passing bool for $amountOrUpOrDown argument of IntlCalendar::roll()
> Accessing static members on traits

No objection.

> strptime()
> strftime() and gmtstrftime()

We have to remember many applications do not need to be portable, as 
they will ever be only run on one setup - the one that the company 
running it has. So non-portability itself should not be a fatal problem. 
I am worried by musl thing mentioned - what exactly happens on musl, 
they don't have strptime()? If it's just different outputs or some 
options not supported, I think it's ok - warning in the docs should be 
enough.


> mhash*() function family

No objection.

> ctype_*() function family accepts int parameters

Here I think adding notice for int arguments would be appropriate, but 
changing the behavior is not - we could cause some very nasty breaks in 
the code if we suddenly change such a basic thing.


> Return by reference with void type
> NIL constant defined by the IMAP extension

No objection.

> Calling overloaded pgsql functions without the connection argument

I hate global state, but there are a lot of old quick-n-dirty scripts 
relying on stuff like that. Can we maybe check how common is usage of 
this pattern?


> $num_points parameter of image(open|filled)polygon
> mysqli::init()

No objection.
--
Stas Malyshev
smalys...@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Matty The Mad]

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 of the nuances.


-Matty

On 2021-03-23 10:52, Sara Golemon wrote:

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 willing to do this every
time we ask, but finding veterans is a bit harder. Maybe we should
take 2 newbies at a time with 1 veteran to increase the size of the
veteran pipeline?


I think that's a great idea, but I think the right way to decide is to
leave it to the veteran who does volunteer for 8.1 to make that call (since
they'll be the one mentoring twice as many newbies).

-Sara



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Sara Golemon]

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 willing to do this every
> time we ask, but finding veterans is a bit harder. Maybe we should
> take 2 newbies at a time with 1 veteran to increase the size of the
> veteran pipeline?
>
I think that's a great idea, but I think the right way to decide is to
leave it to the veteran who does volunteer for 8.1 to make that call (since
they'll be the one mentoring twice as many newbies).

-Sara

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

[Sara Golemon]

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 the future.
>
>
It's not first-come-first-served, we're calling for volunteers and will
have a vote in mid-April (see initial post from me).  Though attention to
detail in written instructions is a plus *wink* ;)

-Sara

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

[Harm Smits]

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 your thoughts @Sara

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

[Levi Morrison via internals]

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 your hat in the ring. Feel free to volunteer now,
> > or any time over the coming weeks.  Additional announcements will be
> > forthcoming as we approach the selection date.  On April 12th
> > (provisional), Gabriel or I will announce the list of candidates and, if
> > more than two candidates have volunteered, open a vote.
> >
> > A description of our release process can be found at
> > https://github.com/php/php-src/blob/master/docs/release-process.md and
> > https://wiki.php.net/rfc/releaseprocess
> >
> > Notably, at least one of the volunteers must be a "veteran" release
> > manager meaning they have participated in at least one release of PHP in
> > the past.  The other may be an additional veteran, or more ideally, someone
> > new to the RM role (in order to increase our supply of veteran RMs).
> > Regardless of who is participating, you'll have access to all active
> > release managers to help get you up and running.
> >
> >
> A gentle reminder to submit yourselves for the PHP 8.1 Release Manager
> job.  It really takes nothing more than a little bit of time.
>
> 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.
>
>  Let's all make PHP awesome!
> -Sara Golemon and Gabriel Caruso, your PHP 8.0 Release Managers

By the way, it seems like we have newbies willing to do this every
time we ask, but finding veterans is a bit harder. Maybe we should
take 2 newbies at a time with 1 veteran to increase the size of the
veteran pipeline?

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Sara Golemon]

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 over the coming weeks.  Additional announcements will be
> forthcoming as we approach the selection date.  On April 12th
> (provisional), Gabriel or I will announce the list of candidates and, if
> more than two candidates have volunteered, open a vote.
>
> A description of our release process can be found at
> https://github.com/php/php-src/blob/master/docs/release-process.md and
> https://wiki.php.net/rfc/releaseprocess
>
> Notably, at least one of the volunteers must be a "veteran" release
> manager meaning they have participated in at least one release of PHP in
> the past.  The other may be an additional veteran, or more ideally, someone
> new to the RM role (in order to increase our supply of veteran RMs).
> Regardless of who is participating, you'll have access to all active
> release managers to help get you up and running.
>
>
A gentle reminder to submit yourselves for the PHP 8.1 Release Manager
job.  It really takes nothing more than a little bit of time.

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.

 Let's all make PHP awesome!
-Sara Golemon and Gabriel Caruso, your PHP 8.0 Release Managers

Re: [PHP-DEV] [VOTE] Fibers

[Niklas Keller]

>
> >> 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 or withdraw RFCs.
> >
> > Although this RFC is reasonably free from drama, I think it was wrong
> > for you to ask for an extension regardless of the current voting. Not
> > only is it improper on its face, but it sets a bad precedent for more
> > drama filled RFCs.
> >
> > cheers
> > Dan
> > Ack
> >
> > btw I would prefer that all RFC votes were longer (e.g. 4 weeks for
> > all decisions that don't have an external time constraint), but
> > changing the end time during the vote is bogus.
>
> I agree with Dan. Also, there was plenty of discussion time for this
> RFC. It’s not like it was rushed.
>

Hey all,

given the wording in the voting rules, the fact that the RFC hasn't been
edited to include the new end date, and due to the objections, I think the
best way forward is closing the voting on the RFC soon. Given no timezone
is mentioned in the RFC, we can probably go with either UTC or UTC-12.
We'll close the vote after UTC-12 passed.

Please create a new thread for discussions about the voting rules in
general that aren't specific for this RFC to keep this thread focused.

Thanks,
Niklas

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

[Sara Golemon]

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 and we should deprecate then
remove those functions without offering a simple replacement.
Christ's sake... no.

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

[Rowan Tommins]

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 the 
line between supported use cases, and requests to re-enable spacebar 
heating: https://xkcd.com/1172/


I think using utf8_encode to store binary data in a text column crosses 
that line: the code was added because of a misunderstanding of the 
function, it works by accident, and there are plenty of better ways to 
solve the actual problem.


Just to be clear, the trick Aleksander and Alexandru stumbled on doesn't 
just work for "corrupted UTF-8"; you could store a JPEG in a text column 
by using utf8_encode(file_get_contents($image_file)). It's probably best 
not to, though.


I *also* agree that users should have a clear guide to how to replace 
their current usages. Fortunately, there are at least 4 other ways of 
writing this functionality in PHP (iconv, mbstring, intl, and the 
Symfony polyfill).


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Fibers

[Ben Ramsey]

> 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 has
> occurred on other RFCs where people have been
> cajoled/pressured/threatened to either suspend votes or withdraw RFCs.
> 
> Although this RFC is reasonably free from drama, I think it was wrong
> for you to ask for an extension regardless of the current voting. Not
> only is it improper on its face, but it sets a bad precedent for more
> drama filled RFCs.
> 
> cheers
> Dan
> Ack
> 
> btw I would prefer that all RFC votes were longer (e.g. 4 weeks for
> all decisions that don't have an external time constraint), but
> changing the end time during the vote is bogus.


I agree with Dan. Also, there was plenty of discussion time for this
RFC. It’s not like it was rushed.

Cheers,
Ben



signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] [VOTE] Fibers

[Chase Peeler]

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 has
> occurred on other RFCs where people have been
> cajoled/pressured/threatened to either suspend votes or withdraw RFCs.
>
>
I agree. I think it puts the RFC author is a bad position too since they
risk upsetting others no matter what they choose to do.


> Although this RFC is reasonably free from drama, I think it was wrong
> for you to ask for an extension regardless of the current voting. Not
> only is it improper on its face, but it sets a bad precedent for more
> drama filled RFCs.
>
> cheers
> Dan
> Ack
>
> btw I would prefer that all RFC votes were longer (e.g. 4 weeks for
> all decisions that don't have an external time constraint), but
> changing the end time during the vote is bogus.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [VOTE] Fibers

[Dan Ackroyd]

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
cajoled/pressured/threatened to either suspend votes or withdraw RFCs.

Although this RFC is reasonably free from drama, I think it was wrong
for you to ask for an extension regardless of the current voting. Not
only is it improper on its face, but it sets a bad precedent for more
drama filled RFCs.

cheers
Dan
Ack

btw I would prefer that all RFC votes were longer (e.g. 4 weeks for
all decisions that don't have an external time constraint), but
changing the end time during the vote is bogus.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Chase Peeler]

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 thing. If that function is saving you from
> errors, it is completely by accident.
>
>
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.


> The same effect can be achieved using base64_encode() and
> base64_decode(), or bin2hex() and hex2bin(), or any other function that
> takes a series of bytes and applies an arbitrary encoding to it.
>
> It could also be achieved by using a binary column type in the database,
> because the values you have stored are not useful as strings; they might
> as well be encrypted.
>
> Given the sequence of bytes "\xE3\x82\zB0", which is a valid UTF-8
> string representing U+30B0 KATAKANA LETTER GU グ calling utf8_encode()
> will result in the sequence of bytes "\xC3\xA3\xC2\x82\xC2\xB0", which
> is the UTF-8 representation of the following Unicode code points:
>
> - U+00E3 LATIN SMALL LETTER A WITH TILDE ã
> - U+0082 CONTROL: BREAK PERMITTED HERE
> - U+00B0 DEGREE SIGN °
>
> This is clearly gibberish, and bears no relationship to the original
> string; it is what is generally referred to as "mojibake".
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepee...@gmail.com

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

[Rowan Tommins]

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 base64.



$str = '嵐嵐';

echo strlen(base64_encode($str));
// 12

echo strlen(utf8_encode($str));
// 16


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Alexandru Pătrănescu]

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
quarter of the available max column space would be lost as a downside.

>
> Regards,
> Alex
>

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

[Rowan Tommins]

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 to write up a separate RFC, to make sure the pros and cons are 
fully understood.


Any feedback on that topic, or suggestions for content of that RFC, 
please reply in the separate thread, to avoid de-railing this one.



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Nikita Popov]

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 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 of changes necessary for
> > PHP 8.0 compatibility.
> >
> > As usual, each deprecation will be voted in isolation.
> >
> > As we're still early in the release cycle, it's still possible to add
> > additional deprecation candidates, given reasoning for the deprecation,
> as
> > well as available alternatives.
> >
> > Of course, if there are compelling technical reasons why something should
> > not be deprecated, we can move things into the "Removed from this
> proposal"
> > section, in which case it will serve as documentation why some
> > functionality should not deprecated.
>
>
> Given Rowan’s thread [1] on `utf8_encode()` and `utf8_decode()`, should we
> consider adding these functions to this list or mentioning them in this
> RFC as being handled separately?
>

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.

Regards,
Nikita

Re: [PHP-DEV] [VOTE] Fibers

[Peter Kokot]

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 don't think extending a vote will in most cases result in the
> > outcome
> > they want (acceptance), but I might be mistaken. In this case however it
> > is a
> > bit meaningless as it's already passing.
> > So I think if there needs to be a discussion about clarifying the voting
> > RFC
> > document it should be made in a different thread.
> >
> > Best regards,
> >
> > George P. Banyard
> >
>
> You're right.  Sorry, I didn't intend to start a debate (nor to be rude to
> Levi), just being probably overly cautious ("better safe than sorry", I
> remembered that some people challenged the validity of votes on the basis
> of "bureaucratic" arguments in the past, and wanted to avoid that here)...
> (In this case I personally find it reasonable, but who am I?)
>
> Just in case, let's record that the result is currently 48:14 ;)
>
> --
> Guilliam Xavier

+1 for extending the voting phase for a week. World will not end. If
anything, everyone will be more confident that the RFC voting results
were the correct choice for further development of async PHP. Even if
one week more would change the voting results, then extending the
voting was a correct choice.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Alexandru Pătrănescu]

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
> documentation wasn't that clear about the function(s) intention. Or the
> intention was different.
>
> ps. to Kamil,
>
> We use utf8_encode() to make the string safe to be put in utf-8 database
> column/table. We use utf8_decode() to convert that back to what it was
> before.
>

I just searched and found a hotfix I did a few years ago (when I was also
dumber) and the fix was just adding a utf8_encode to some data received in
$_POST before being sent to a logging service. And a utf8_decode after
reading it for further parsing.
The logging service storage was using a mysql database and the specific
column was declared `TEXT` instead of `BLOB`.
Apparently the fix is still in place.


>
> The tests prove that the conversion is lossless.
>

There could have been better ways to fix it.
json_encode / json_decode would have worked just the same.

The problem was that the quickly identified cause was a non-utf8 string
trying to be stored in an utf8 text column and the solution was implemented
based on the fact that utf8_decode/encode sounded like a good idea when
time is limited; and also knowledge in my case.
I think it would be great to deprecate them somehow.

Regards,
Alex

Re: [PHP-DEV] [VOTE] Fibers

[Guilliam Xavier]

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
> they want (acceptance), but I might be mistaken. In this case however it
> is a
> bit meaningless as it's already passing.
> So I think if there needs to be a discussion about clarifying the voting
> RFC
> document it should be made in a different thread.
>
> Best regards,
>
> George P. Banyard
>

You're right.  Sorry, I didn't intend to start a debate (nor to be rude to
Levi), just being probably overly cautious ("better safe than sorry", I
remembered that some people challenged the validity of votes on the basis
of "bureaucratic" arguments in the past, and wanted to avoid that here)...
(In this case I personally find it reasonable, but who am I?)

Just in case, let's record that the result is currently 48:14 ;)

-- 
Guilliam Xavier

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

[Rowan Tommins]

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 by accident.


The same effect can be achieved using base64_encode() and 
base64_decode(), or bin2hex() and hex2bin(), or any other function that 
takes a series of bytes and applies an arbitrary encoding to it.


It could also be achieved by using a binary column type in the database, 
because the values you have stored are not useful as strings; they might 
as well be encrypted.


Given the sequence of bytes "\xE3\x82\zB0", which is a valid UTF-8 
string representing U+30B0 KATAKANA LETTER GU グ calling utf8_encode() 
will result in the sequence of bytes "\xC3\xA3\xC2\x82\xC2\xB0", which 
is the UTF-8 representation of the following Unicode code points:


- U+00E3 LATIN SMALL LETTER A WITH TILDE ã
- U+0082 CONTROL: BREAK PERMITTED HERE
- U+00B0 DEGREE SIGN °

This is clearly gibberish, and bears no relationship to the original 
string; it is what is generally referred to as "mojibake".


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Björn Larsson]

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 years. This RFC was formerly targeted at PHP 8.0,
but was delayed to PHP 8.1 to reduce the amount of changes necessary for
PHP 8.0 compatibility.

As usual, each deprecation will be voted in isolation.

As we're still early in the release cycle, it's still possible to add
additional deprecation candidates, given reasoning for the deprecation, as
well as available alternatives.

Of course, if there are compelling technical reasons why something should
not be deprecated, we can move things into the "Removed from this proposal"
section, in which case it will serve as documentation why some
functionality should not deprecated.



Given Rowan’s thread [1] on `utf8_encode()` and `utf8_decode()`, should we
consider adding these functions to this list or mentioning them in this
RFC as being handled separately?

Cheers,
Ben

[1] https://externals.io/message/113645


In order for that I think a clearer / better motivation is needed.

For instance bug reports or community / documented feedback that these 
functions are giving rise to problems / are misused.


Maybe also a checking how frequently thay are used in different Open 
source libraries. Found several occurences in the Revive ad server.


r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Mike Schinkel]

> 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 stdlib has been coming up a lot recently,
> > so I'd like to present my own stab at resolving this question:
> > 
> > https://wiki.php.net/rfc/namespaces_in_bundled_extensions 
> > 
> > 
> > Relative to a number of previous (declined) proposals, the main difference
> > is that I do not propose a top-level "PHP\" vendor namespace, and instead
> > recommend the use of "ExtName\", in line with existing practice for
> > extensions. I believe this addresses the primary concern with previous
> > proposals.
> 
> Hi Nikita,
> 
> Can I request/suggest that if we are going to take this approach that the RFC 
> also adds an "advisory" registry for namespaces in the form of a Github repo 
> with parallel README.md and namespaces.json files containing "registered" 
> namespaces and a link for more information?
> 
> The benefit of such a registry would be to allow people who want to avoid 
> using a namespace others are already using in public to find the list of 
> namespaces for code that has been published publicly. Full stop.
> 
> For what I am proposing, the registry would NOT be used to _stop_ people from 
> using "registered" namespaces. They would be free to do so if they chose to. 
> The registry would instead be for those who want to ensure their code is most 
> likely to play nice with anyone else's code.
> 
> The registration process would be as simple as submitting a PR that includes 
> the requested namespace added to both the README.md and the namespaces.json 
> file along with a link for more information.
> 
> There would not be any approval process per se other than merging the PR, and 
> there would not be any "owner" of the registration per se as registration 
> would merely be a stake in the ground to recommend others not use that same 
> namespace. 
> 
> I'd suggest registration of really generic namespaces would be discouraged, 
> but not disallowed.
> 
> I envision the link to more information would be a link to a git repo with 
> either the code or information about the namespace in the README.  If after a 
> namespace is registered we find that other people/organizations are using the 
> same namespace then the maintainers of the repo could choose to add multiple 
> links to the same namespace.
> 
> Again, in summary, this list of "registrations" would be to allow people to 
> easily find out if the namespace they want to use has already been used 
> publicly by others, and if not to allow them to "register" it for their use.
> 
> If maintainers of the repo discover and PR behavior that is suspect, they 
> could bring to the internals list to discuss a resolution. But unless and 
> until that happens, governance of this registry would be as minimal as 
> possible.
> 
> Is this something you can/will add to your RFC?
> 
> -Mike
> P.S. If this existed it would be something PhpStorm (and VSCode) could 
> probably use to help developers who find namespaces in code to be able to 
> find out where they can learn more about those namespaces.  And later, the 
> git repo could publish a namespace.json with a lot more information about the 
> namespace that could help PhpStorm offer even more help to developers.  
> #justsaying
> 
> No, I am not willing to add a namespace registry to the RFC.
> 
> I do acknowledge that the lack of vendor prefix may make namespace collisions 
> more likely, although an important mitigating factor here is that that 
> userland libraries (unlike existing extensions) do typically use a vendor 
> namespace, and vendor namespaces usually do not collide with component 
> namespaces.

I appreciate and respect your decision.

> I also think that there should be some common courtesy involved in the choice 
> of namespaces -- if there is some really popular unvendored open-source 
> library out there that already uses some namespace prefix, we definitely 
> should consider that in our naming decisions.
> 
> But I don't think this needs any formal process of namespace registration, 
> which creates unnecessary bureaucracy and misaligned expectations. If your 
> library is important enough, then people will be aware of the issue. The 
> converse also holds.

But I do want to point out it can be difficult to discover namespaces that may 
conflict when they are not the main namespace for a popular open-source 
solution. So it sucks for the developer who wants to use two conflicting "not 
important enough" libraries.

But I do accept that this idea is a no-go in your RFC.

-Mike

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

[Christoph M. Becker]

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:
> https://github.com/php/php-src/pull/6677
> which addresses an open issue in the bug tracker:
> https://bugs.php.net/bug.php?id=51499

The problem is that many consider adding driver specific methods to the
PDO class a no-go.  That resulted in a PDO_SQLITE specific RFC[1] to be
declined.  The preferred solution apparently would be to introduce
proper subclasses for each driver.  I am not sure whether this is viable
at all, though.  Unfortunate situation. :(

[1] 

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Aleksander Machniak]

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
intention was different.

ps. to Kamil,

We use utf8_encode() to make the string safe to be put in utf-8 database
column/table. We use utf8_decode() to convert that back to what it was
before.

The tests prove that the conversion is lossless.

-- 
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] [VOTE] Fibers

[G. P. B.]

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 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 Fri, Mar 19, 2021 at 3:54 PM Niklas Keller > > > wrote:
>> > >> >>
>> > >> >> Hey Levi,
>> > >> >>
>> > >> >>> On Mon, Mar 8, 2021 at 12:40 PM Aaron Piotrowski <
>> aa...@trowski.com>
>> > wrote:
>> > >> 
>> > >>  Greetings everyone!
>> > >> 
>> > >>  The vote has started on the fiber RFC:
>> > https://wiki.php.net/rfc/fibers 
>> > >> 
>> > >>  Voting will run through March 22nd.
>> > >> 
>> > >>  Cheers,
>> > >>  Aaron Piotrowski
>> > >> >>>
>> > >> >>> This is selfish, but I would like to kindly request lengthening
>> the
>> > >> >>> voting window to allow me more time to play with it. I feel like
>> I
>> > >> >>> can't vote "yes" on something like this without more experience
>> with
>> > >> >>> it (which is why I currently have voted "no"). I hope others
>> would
>> > >> >>> play with it more as well if we had more time. Any objections?
>> > >> >>
>> > >> >>
>> > >> >> How much time do you think you need?
>> > >> >
>> > >> > Another week seems reasonable; enough time to evaluate it more
>> > >> > thoroughly but not delay things seriously.
>> > >>
>> > >> This is fine with me. Let's extend voting for about another week,
>> > ending on 3/28 at about 11 PM EDT.
>> > >
>> > >
>> > > I'm afraid you can't: from https://wiki.php.net/rfc/voting#voting
>> > >
>> > > > A valid voting period must be declared when voting is started and
>> must
>> > not be changed during the vote.
>> > >
>> > > (Not that I care personally, but you would take the risk of the vote
>> > being invalidated...)
>> > >
>> > > --
>> > > Guilliam Xavier
>> >
>> > 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 be declared when voting is started and must
>> > not be changed during the vote.
>> >
>>
>> The history is , but I
>> don't
>> think it conflicts: to my understanding, what "may be extended" is the
>> chosen duration vs the minimum duration (e.g. the author can chose to open
>> a vote for an "extended" 4-weeks period instead of 2-weeks), and that
>> choice must be set before starting.
>>
>> Arguably the wording is maybe not the clearest, but there's also this
>> from <
>> https://externals.io/message/104860>:
>>
>> >> +1, but it should probably be possible to extend the voting period once
>> started, but not shorten it. This allows for extension during holidays in
>> case the author didn't think about that when starting the vote.
>> >
>> > Allowing the extension of voting leaves us open to someone extending the
>> voting period simply because they don't feel like they have the result
>> they
>> wanted.
>>
>> Anyway I just wanted to warn (it would be a shame to see the vote result
>> being debated after an extra week), but that may be OK to the "deciders".
>>
>> Regards,
>>
>> --
>> Guilliam Xavier
>>
>
>

Apologies for the empty email, pressed enter twice too fast for my client...

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
they want (acceptance), but I might be mistaken. In this case however it is
a
bit meaningless as it's already passing.
So I think if there needs to be a discussion about clarifying the voting RFC
document it should be made in a different thread.

Best regards,

George P. Banyard

Re: [PHP-DEV] [VOTE] Fibers

[G. P. B.]

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 5:47 PM, Levi Morrison <
> > levi.morri...@datadoghq.com> wrote:
> > >> >
> > >> > On Fri, Mar 19, 2021 at 3:54 PM Niklas Keller  > > wrote:
> > >> >>
> > >> >> Hey Levi,
> > >> >>
> > >> >>> On Mon, Mar 8, 2021 at 12:40 PM Aaron Piotrowski <
> aa...@trowski.com>
> > wrote:
> > >> 
> > >>  Greetings everyone!
> > >> 
> > >>  The vote has started on the fiber RFC:
> > https://wiki.php.net/rfc/fibers 
> > >> 
> > >>  Voting will run through March 22nd.
> > >> 
> > >>  Cheers,
> > >>  Aaron Piotrowski
> > >> >>>
> > >> >>> This is selfish, but I would like to kindly request lengthening
> the
> > >> >>> voting window to allow me more time to play with it. I feel like I
> > >> >>> can't vote "yes" on something like this without more experience
> with
> > >> >>> it (which is why I currently have voted "no"). I hope others would
> > >> >>> play with it more as well if we had more time. Any objections?
> > >> >>
> > >> >>
> > >> >> How much time do you think you need?
> > >> >
> > >> > Another week seems reasonable; enough time to evaluate it more
> > >> > thoroughly but not delay things seriously.
> > >>
> > >> This is fine with me. Let's extend voting for about another week,
> > ending on 3/28 at about 11 PM EDT.
> > >
> > >
> > > I'm afraid you can't: from https://wiki.php.net/rfc/voting#voting
> > >
> > > > A valid voting period must be declared when voting is started and
> must
> > not be changed during the vote.
> > >
> > > (Not that I care personally, but you would take the risk of the vote
> > being invalidated...)
> > >
> > > --
> > > Guilliam Xavier
> >
> > 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 be declared when voting is started and must
> > not be changed during the vote.
> >
>
> The history is , but I don't
> think it conflicts: to my understanding, what "may be extended" is the
> chosen duration vs the minimum duration (e.g. the author can chose to open
> a vote for an "extended" 4-weeks period instead of 2-weeks), and that
> choice must be set before starting.
>
> Arguably the wording is maybe not the clearest, but there's also this from
> <
> https://externals.io/message/104860>:
>
> >> +1, but it should probably be possible to extend the voting period once
> started, but not shorten it. This allows for extension during holidays in
> case the author didn't think about that when starting the vote.
> >
> > Allowing the extension of voting leaves us open to someone extending the
> voting period simply because they don't feel like they have the result they
> wanted.
>
> Anyway I just wanted to warn (it would be a shame to see the vote result
> being debated after an extra week), but that may be OK to the "deciders".
>
> Regards,
>
> --
> Guilliam Xavier
>

Re: [PHP-DEV] [VOTE] Fibers

[Guilliam Xavier]

>
> 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 there are three
possible outcomes:
> 1. Your RFC is accepted: [...]
> 2. Your RFC is declined: [...]
> 3. A serious issue with your RFC needs to be addressed: update the
status of your RFC page and its section on https://wiki.php.net/RFC to
“Under Discussion” and continue again from step 5.

(where "step 5" refers to the discussion phase)

Regards,

-- 
Guilliam Xavier

Re: [PHP-DEV] [VOTE] Fibers

[Guilliam Xavier]

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 Fri, Mar 19, 2021 at 3:54 PM Niklas Keller  > wrote:
> >> >>
> >> >> Hey Levi,
> >> >>
> >> >>> On Mon, Mar 8, 2021 at 12:40 PM Aaron Piotrowski 
> wrote:
> >> 
> >>  Greetings everyone!
> >> 
> >>  The vote has started on the fiber RFC:
> https://wiki.php.net/rfc/fibers 
> >> 
> >>  Voting will run through March 22nd.
> >> 
> >>  Cheers,
> >>  Aaron Piotrowski
> >> >>>
> >> >>> This is selfish, but I would like to kindly request lengthening the
> >> >>> voting window to allow me more time to play with it. I feel like I
> >> >>> can't vote "yes" on something like this without more experience with
> >> >>> it (which is why I currently have voted "no"). I hope others would
> >> >>> play with it more as well if we had more time. Any objections?
> >> >>
> >> >>
> >> >> How much time do you think you need?
> >> >
> >> > Another week seems reasonable; enough time to evaluate it more
> >> > thoroughly but not delay things seriously.
> >>
> >> This is fine with me. Let's extend voting for about another week,
> ending on 3/28 at about 11 PM EDT.
> >
> >
> > I'm afraid you can't: from https://wiki.php.net/rfc/voting#voting
> >
> > > A valid voting period must be declared when voting is started and must
> not be changed during the vote.
> >
> > (Not that I care personally, but you would take the risk of the vote
> being invalidated...)
> >
> > --
> > Guilliam Xavier
>
> 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 be declared when voting is started and must
> not be changed during the vote.
>

The history is , but I don't
think it conflicts: to my understanding, what "may be extended" is the
chosen duration vs the minimum duration (e.g. the author can chose to open
a vote for an "extended" 4-weeks period instead of 2-weeks), and that
choice must be set before starting.

Arguably the wording is maybe not the clearest, but there's also this from <
https://externals.io/message/104860>:

>> +1, but it should probably be possible to extend the voting period once
started, but not shorten it. This allows for extension during holidays in
case the author didn't think about that when starting the vote.
>
> Allowing the extension of voting leaves us open to someone extending the
voting period simply because they don't feel like they have the result they
wanted.

Anyway I just wanted to warn (it would be a shame to see the vote result
being debated after an extra week), but that may be OK to the "deciders".

Regards,

-- 
Guilliam Xavier

Re: [PHP-DEV] [VOTE] Fibers

[Levi Morrison via internals]

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 may be extended, for example during holiday periods.
> >> A valid voting period must be declared when voting is started and must not 
> >> be changed during the vote.
>
>
> I don't think there's a conflict there; there's two separate requirements:
>
> * The duration must be at least two weeks, but may be longer.
> * The duration must be specified before the vote starts.
>
>
> The phrase "may be extended" is referring to *who* can make the
> decision, not *when* they can make it.
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

I disagree that it is unambiguous. You missed the important part (to
me, at least), though: what is the history for this edit? Why was it
made? I do not recall discussing this formally at any point (but of
course, I may have missed it or forgot). Quick check on version
history says 2 years ago.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Fibers

[Ben Ramsey]

> 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 at 3:54 PM Niklas Keller >>> > wrote:
> 
> Hey Levi,
> 
>> On Mon, Mar 8, 2021 at 12:40 PM Aaron Piotrowski  
>> wrote:
>>> 
>>> Greetings everyone!
>>> 
>>> The vote has started on the fiber RFC: https://wiki.php.net/rfc/fibers 
>>> 
>>> 
>>> Voting will run through March 22nd.
>>> 
>>> Cheers,
>>> Aaron Piotrowski
>> 
>> This is selfish, but I would like to kindly request lengthening the
>> voting window to allow me more time to play with it. I feel like I
>> can't vote "yes" on something like this without more experience with
>> it (which is why I currently have voted "no"). I hope others would
>> play with it more as well if we had more time. Any objections?
> 
> 
> How much time do you think you need?
 
 Another week seems reasonable; enough time to evaluate it more
 thoroughly but not delay things seriously.
>>> 
>>> This is fine with me. Let's extend voting for about another week, ending on 
>>> 3/28 at about 11 PM EDT.
>> 
>> 
>> I'm afraid you can't: from https://wiki.php.net/rfc/voting#voting
>> 
>>> A valid voting period must be declared when voting is started and must not 
>>> be changed during the vote.
>> 
>> (Not that I care personally, but you would take the risk of the vote being 
>> invalidated...)
>> 
>> --
>> Guilliam Xavier
> 
> 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 be declared when voting is started and must not 
>> be changed during the vote.


I interpret that line to mean that the author may decide to extend the
voting period prior to declaring the valid voting period when voting is
started.

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.

Cheers,
Ben




signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] [VOTE] Fibers

[Rowan Tommins]

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 be declared when voting is started and must not be 
changed during the vote.



I don't think there's a conflict there; there's two separate requirements:

* The duration must be at least two weeks, but may be longer.
* The duration must be specified before the vote starts.


The phrase "may be extended" is referring to *who* can make the 
decision, not *when* they can make it.



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Rowan Tommins]

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 name 
makes you think that is exactly why I want to get rid of that name.




 $str = "グーグル谷歌中信фδοκιμήóźdźрöß";

 $this->assertSame($str, utf8_decode(utf8_encode($str)));



Let's write that out with a more descriptive function name:

$str = "グーグル谷歌中信фδοκιμήóźdźрöß";

$this->assertSame($str, utf8_to_latin1(latin1_to_utf8($str)));


Since Latin-1 does not contain any Chinese, Japanese, or Emoji 
characters, running latin1_to_uft8 on that string is clearly nonsensical.


The only reason it doesn't give you any errors is that every possible 
byte is a valid character in Latin1, and every Latin1 character has a 
Unicode code point. So the "グ" is interpreted as three Latin-1 
characters: E3, 82, and B0; those then become the corresponding Unicode 
code points U+00E3, U+00821, and U+00B0, represented in UTF-8. You then 
run utf8_to_latin1, and they get converted back.


That code will never do anything useful.

Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Fibers

[Levi Morrison via internals]

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 Levi,
>> >>
>> >>> On Mon, Mar 8, 2021 at 12:40 PM Aaron Piotrowski  
>> >>> wrote:
>> 
>>  Greetings everyone!
>> 
>>  The vote has started on the fiber RFC: https://wiki.php.net/rfc/fibers 
>>  
>> 
>>  Voting will run through March 22nd.
>> 
>>  Cheers,
>>  Aaron Piotrowski
>> >>>
>> >>> This is selfish, but I would like to kindly request lengthening the
>> >>> voting window to allow me more time to play with it. I feel like I
>> >>> can't vote "yes" on something like this without more experience with
>> >>> it (which is why I currently have voted "no"). I hope others would
>> >>> play with it more as well if we had more time. Any objections?
>> >>
>> >>
>> >> How much time do you think you need?
>> >
>> > Another week seems reasonable; enough time to evaluate it more
>> > thoroughly but not delay things seriously.
>>
>> This is fine with me. Let's extend voting for about another week, ending on 
>> 3/28 at about 11 PM EDT.
>
>
> I'm afraid you can't: from https://wiki.php.net/rfc/voting#voting
>
> > A valid voting period must be declared when voting is started and must not 
> > be changed during the vote.
>
> (Not that I care personally, but you would take the risk of the vote being 
> invalidated...)
>
> --
> Guilliam Xavier

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 be declared when voting is started and must not be 
> changed during the vote.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Kamil Tekiela]

>
> 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 utf8_decode(utf8_encode($str)) should just be an identity
function. Could you please explain what is the purpose of using these
functions in such a way?

Re: [PHP-DEV] [VOTE] Fibers

[Guilliam Xavier]

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:
> 
>  Greetings everyone!
> 
>  The vote has started on the fiber RFC:
> https://wiki.php.net/rfc/fibers 
> 
>  Voting will run through March 22nd.
> 
>  Cheers,
>  Aaron Piotrowski
> >>>
> >>> This is selfish, but I would like to kindly request lengthening the
> >>> voting window to allow me more time to play with it. I feel like I
> >>> can't vote "yes" on something like this without more experience with
> >>> it (which is why I currently have voted "no"). I hope others would
> >>> play with it more as well if we had more time. Any objections?
> >>
> >>
> >> How much time do you think you need?
> >
> > Another week seems reasonable; enough time to evaluate it more
> > thoroughly but not delay things seriously.
>
> This is fine with me. Let's extend voting for about another week, ending
> on 3/28 at about 11 PM EDT.
>

I'm afraid you can't: from https://wiki.php.net/rfc/voting#voting

> A valid voting period must be declared when voting is started and must
not be changed during the vote.

(Not that I care personally, but you would take the risk of the vote being
invalidated...)

-- 
Guilliam Xavier

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

[Aleksander Machniak]

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 most cases the input is utf-8, but it
occasionally may contain "broken characters".

$str = '';
for ($x=0; $x<256; $x++) {
$str .= chr($x);
}

$this->assertSame($str, utf8_decode(utf8_encode($str)));

$str = "グーグル谷歌中信фδοκιμήóźdźрöß";

$this->assertSame($str, utf8_decode(utf8_encode($str)));

Could anyone point to a sample input that will not work with my use-case?

-- 
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] Deprecations for PHP 8.1

[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 years. This RFC was formerly targeted at PHP 8.0,
> but was delayed to PHP 8.1 to reduce the amount of changes necessary for
> PHP 8.0 compatibility.
> 
> As usual, each deprecation will be voted in isolation.
> 
> As we're still early in the release cycle, it's still possible to add
> additional deprecation candidates, given reasoning for the deprecation, as
> well as available alternatives.
> 
> Of course, if there are compelling technical reasons why something should
> not be deprecated, we can move things into the "Removed from this proposal"
> section, in which case it will serve as documentation why some
> functionality should not deprecated.


Given Rowan’s thread [1] on `utf8_encode()` and `utf8_decode()`, should we
consider adding these functions to this list or mentioning them in this
RFC as being handled separately?

Cheers,
Ben

[1] https://externals.io/message/113645


signature.asc
Description: Message signed with OpenPGP

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

[Rowan Tommins]

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 get to sleep 
that a pure-PHP implementation would be fairly straight-forward because 
of the relationship between Latin1 and Unicode.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Rowan Tommins]

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. Someone using the function correctly to convert 
to ISO 8859-1 may also be relying on the documented and consistent 
error-handling behaviour. Substituting the character may not always be 
the best approach, but in some cases it's more useful than discarding 
the entire string, let alone aborting the entire process with an 
unhandled Throwable.



The goal is only to not punish users by taking away a valid API that 
they were using correctly (for those users who were using it correctly).



I'm sympathetic to that aim, but if the new function is not the same, 
you *are* taking away the existing API, and introducing a new one. 
Neither of the following seems like it would be accepted:


- Make utf8_decode() throw errors for unrepresentable characters.
- Introduce a function specifically for converting from UTF-8 to 
Latin-1, if we didn't already have one.


So it feels questionable to me to design a new function, which is 
neither compatible with what we have, nor a reasonable addition on its 
own merits.



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Björn Larsson]

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 not given.



I don't feel strongly about indefinite deprecation.  If you wanna nuke it
in 9.0, have fun.  I'm just saying I don't necessarily see the need to do
so.  The problem being addressed here is that *some* users of this function
are probably misusing it, so it's worth putting guiderails on.  I'm
hesitant to punish the ones who know exactly what they're doing as a result
of that well-meaning intention.


* 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.


* People who want to write a polyfill couldn't use it, because they
wouldn't be able to recover the remainder of the string after an error
is thrown.



If you're writing a polyfill, then write a polyfill.   The polyfill for the
old functions is trivial, I could have written it a dozen times in the
course of writing this email reply.
So this replacement is also not for them.


* People who want transcoding without any optional extensions will be
disappointed to find only this one encoding supported.


This function isn't for them.It's for people using iso-8859-1.

There's a theme in here. :)


You'd effectively be adding a completely new core function just for
those people who work with Latin1 text, and are confident that it's not
Windows-1252 in disguise.



Yes.  I'm specifically addressing the people who have been using
utf8_en/decode() correctly all this time.  They shouldn't be punished for
the stupidity of others.


It's tempting to make any C1 control characters an error as well -
although technically valid in Latin1, these are very rarely used, and
it's much more likely that any bytes in that range are intended as
characters in Windows-1252. But that would feel very odd without having
a corresponding utf8_from_windows1252 function to use instead, at which
point we're into designing a whole new conversion library. And of
course, once you've got that UTF-8 string, you can't do much with it,
because PHP's native string functions are all byte-based, so you've
basically got to re-invent large chunks of ext/mbstring...



I disagree that you'd need to add utf8_from/to_windows1252 "for
completeness".  The goal isn't to provide all possible conversion
utilities.  The goal is only to not punish users by taking away a valid API
that they were using correctly (for those users who were using it
correctly).


-Sara




Think I'm one such user :-) So keeping them and improving a little would
be fine with me!

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Nicolas Grekas]

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 strong preference for a replacement built
> > into the core (i.e. guaranteed available without any optional packages)?
> >
>
> Can you clarify what *YOU* mean by a polyfill?  Because you're talking
> about dependence on iconv/mbstring/icu which implies you want a polyfill
> that does something other than what the original utf8_en/decode() functions
> do, and those functions certainly do not need external dependencies.
> They're really just not that complex.
>

Shameless plug: the polyfill exists, without any dependency, see
https://github.com/symfony/polyfill-php72/blob/main/Php72.php

;)
Nicolas

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

[Sara Golemon]

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. guaranteed available without any optional packages)?
>

Can you clarify what *YOU* mean by a polyfill?  Because you're talking
about dependence on iconv/mbstring/icu which implies you want a polyfill
that does something other than what the original utf8_en/decode() functions
do, and those functions certainly do not need external dependencies.
They're really just not that complex.

-Sara

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

[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 not given.
>

I don't feel strongly about indefinite deprecation.  If you wanna nuke it
in 9.0, have fun.  I'm just saying I don't necessarily see the need to do
so.  The problem being addressed here is that *some* users of this function
are probably misusing it, so it's worth putting guiderails on.  I'm
hesitant to punish the ones who know exactly what they're doing as a result
of that well-meaning intention.

> * 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.

> * People who want to write a polyfill couldn't use it, because they
> wouldn't be able to recover the remainder of the string after an error
> is thrown.
>

If you're writing a polyfill, then write a polyfill.   The polyfill for the
old functions is trivial, I could have written it a dozen times in the
course of writing this email reply.
So this replacement is also not for them.

> * People who want transcoding without any optional extensions will be
> disappointed to find only this one encoding supported.
>
This function isn't for them.It's for people using iso-8859-1.

There's a theme in here. :)

> You'd effectively be adding a completely new core function just for
> those people who work with Latin1 text, and are confident that it's not
> Windows-1252 in disguise.
>

Yes.  I'm specifically addressing the people who have been using
utf8_en/decode() correctly all this time.  They shouldn't be punished for
the stupidity of others.

> It's tempting to make any C1 control characters an error as well -
> although technically valid in Latin1, these are very rarely used, and
> it's much more likely that any bytes in that range are intended as
> characters in Windows-1252. But that would feel very odd without having
> a corresponding utf8_from_windows1252 function to use instead, at which
> point we're into designing a whole new conversion library. And of
> course, once you've got that UTF-8 string, you can't do much with it,
> because PHP's native string functions are all byte-based, so you've
> basically got to re-invent large chunks of ext/mbstring...
>

I disagree that you'd need to add utf8_from/to_windows1252 "for
completeness".  The goal isn't to provide all possible conversion
utilities.  The goal is only to not punish users by taking away a valid API
that they were using correctly (for those users who were using it
correctly).

> -Sara

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

[Björn Larsson]

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 flawlessly, so for us it's super
important to have a clear migration path with a good polyfill! 



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. guaranteed available without any optional packages)?


Regards,



Well, both these extensions are part of our environment so I presume it
will also be so in the future.

Now if we have a polyfill dependent on these libraries it's a question
on how these libraries are maintained and that they are not EOL. Just 
speaking from a general point here. I'm in slight favour of mbstring,

since I have a small experience of it.

What's important for us is that the polyfill has a simple API and 
doesn't have any surprises / side effects. I think though there is

a case for improving these functions and keep them in the core.

We wrap these functions in one place so it's relatively easy to change 
the wrapper to accomodate new functionality in the utf8_* functions as

long as we get the same end result.

I also think one should consider which opensource libraries that are
using these functions. E.g. the Revive ad server v5.2 are using both.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Nicolas Grekas]

>
> 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 have a new proposal:

We should replace the SuppressReturnTypeNotice by the TentativeReturnType
one right away.
The TentativeReturnType would mean: "I'm going to add a return type to this
method in its next major".
As a consequence, for child classes of internal methods, this would
suppress the notice.
For userland, there are already ways to declare the planned return type
(aka @return in phpdoc), so we might not need any new way to declare this
from the engine pov.
As a corollary, adding this attribute should conflict with having a real
return type.

That would allow userland libs to immediately adopt the tag and be ready
for PHP 8.1.

WDYT?

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

[Máté Kocsis]

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 future, unless
any major concern arises. So it's the best time to bring these concerns up.
:)

Máté

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

[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 flawlessly, so for us it's super
important to have a clear migration path with a good polyfill! 



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. guaranteed available without any optional packages)?


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Björn Larsson]

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 packages that users can't or don't know how to install. Maybe 
we've got an opportunity to think about making these extensions 
mandatory?



It's somewhat relevant that until PHP 7.2, it was also possible for 
utf8_encode and utf8_decode to be missing, because they were in ext/xml, 
which is also optional.


Bundling mbstring sounds great, until you look into the details of 
what's in there and how it works. Its origin as a PHP 4 extension for 
handling Japanese-specific character encodings is visible in parts of 
its design - there's a lot of global state, and very little support for 
the nuances of Unicode.


Bundling intl would be great, but it's a wrapper around ICU, which is 
huge (because Unicode is complicated). I have read that incorporating 
that into core was one of the icebergs that sunk PHP 6. It's also 
extremely sparsely documented (if someone's looking for a project, it 
would be great to fill in all the manual stubs with a few details from 
the corresponding ICU documentation).


For what its worth, it seems these would be the relevant polyfills:

function utf8_encode(string $string) { return 
UConverter::transcode($string, 'UTF8', 'ISO-8859-1'); }
function utf8_decode(string $string) { return 
UConverter::transcode($string, 'ISO-8859-1', 'UTF8'); }



Regards,



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 migration path with a good polyfill!

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Rowan Tommins]

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 future, 
even if a specific timeline for that removal is not given.


If we want to have a separate status of "will be kept indefinitely, but 
you shouldn't use it", then we need a separate E_DISCOURAGED, or some 
boilerplate in the manual which doesn't use the word "deprecated".



As for details, I don't love iso_8859_1_to_utf8(), but we can use the 
common alias for iso-8859-1 known as latin1 and call the new 
functions: utf8_from_latin1() and utf8_to_latin1() with the caveat 
that the later will throw a ValueError for codepoints which are out of 
range (one of the more problematic issues with utf8_decode()). That 
makes this not just a simple rename for clarity, but what I'd consider 
a bug-fix for an unfortunately unfixable function.



While I can see the temptation here, I'm not sure who the target 
audience for the new function would be:


* People who just want to replace calls to utf8_decode won't want to go 
through every call and make it exception safe.
* People who want to write a polyfill couldn't use it, because they 
wouldn't be able to recover the remainder of the string after an error 
is thrown.
* People who want transcoding without any optional extensions will be 
disappointed to find only this one encoding supported.


You'd effectively be adding a completely new core function just for 
those people who work with Latin1 text, and are confident that it's not 
Windows-1252 in disguise.


It's tempting to make any C1 control characters an error as well - 
although technically valid in Latin1, these are very rarely used, and 
it's much more likely that any bytes in that range are intended as 
characters in Windows-1252. But that would feel very odd without having 
a corresponding utf8_from_windows1252 function to use instead, at which 
point we're into designing a whole new conversion library. And of 
course, once you've got that UTF-8 string, you can't do much with it, 
because PHP's native string functions are all byte-based, so you've 
basically got to re-invent large chunks of ext/mbstring...



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Nikita Popov]

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:
> >
> > https://wiki.php.net/rfc/namespaces_in_bundled_extensions
> >
> > Relative to a number of previous (declined) proposals, the main
> difference
> > is that I do not propose a top-level "PHP\" vendor namespace, and instead
> > recommend the use of "ExtName\", in line with existing practice for
> > extensions. I believe this addresses the primary concern with previous
> > proposals.
>
> Hi Nikita,
>
> Can I request/suggest that if we are going to take this approach that the
> RFC also adds an "advisory" registry for namespaces in the form of a Github
> repo with parallel README.md and namespaces.json files containing
> "registered" namespaces and a link for more information?
>
> The benefit of such a registry would be to allow people who want to avoid
> using a namespace others are already using in public to find the list of
> namespaces for code that has been published publicly. Full stop.
>
> For what I am proposing, the registry would NOT be used to _stop_ people
> from using "registered" namespaces. They would be free to do so if they
> chose to. The registry would instead be for those who want to ensure their
> code is most likely to play nice with anyone else's code.
>
> The registration process would be as simple as submitting a PR that
> includes the requested namespace added to both the README.md and the
> namespaces.json file along with a link for more information.
>
> There would not be any approval process per se other than merging the PR,
> and there would not be any "owner" of the registration per se as
> registration would merely be a stake in the ground to recommend others not
> use that same namespace.
>
> I'd suggest registration of really generic namespaces would be
> discouraged, but not disallowed.
>
> I envision the link to more information would be a link to a git repo with
> either the code or information about the namespace in the README.  If after
> a namespace is registered we find that other people/organizations are using
> the same namespace then the maintainers of the repo could choose to add
> multiple links to the same namespace.
>
> Again, in summary, this list of "registrations" would be to allow people
> to easily find out if the namespace they want to use has already been used
> publicly by others, and if not to allow them to "register" it for their use.
>
> If maintainers of the repo discover and PR behavior that is suspect, they
> could bring to the internals list to discuss a resolution. But unless and
> until that happens, governance of this registry would be as minimal as
> possible.
>
> Is this something you can/will add to your RFC?
>
> -Mike
> P.S. If this existed it would be something PhpStorm (and VSCode) could
> probably use to help developers who find namespaces in code to be able to
> find out where they can learn more about those namespaces.  And later, the
> git repo could publish a namespace.json with a lot more information about
> the namespace that could help PhpStorm offer even more help to developers.
> #justsaying
>

No, I am not willing to add a namespace registry to the RFC.

I do acknowledge that the lack of vendor prefix may make namespace
collisions more likely, although an important mitigating factor here is
that that userland libraries (unlike existing extensions) do typically use
a vendor namespace, and vendor namespaces usually do not collide with
component namespaces.

I also think that there should be some common courtesy involved in the
choice of namespaces -- if there is some really popular unvendored
open-source library out there that already uses some namespace prefix, we
definitely should consider that in our naming decisions. But I don't think
this needs any formal process of namespace registration, which creates
unnecessary bureaucracy and misaligned expectations. If your library is
important enough, then people will be aware of the issue. The converse also
holds.

Regards,
Nikita

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

[Nikita Popov]

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 additional parameter
now, otherwise an LSP error will be thrown. I believe that's acceptable
breakage though.

Regards,
Nikita

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

[Nikita Popov]

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 of changes necessary for
PHP 8.0 compatibility.

As usual, each deprecation will be voted in isolation.

As we're still early in the release cycle, it's still possible to add
additional deprecation candidates, given reasoning for the deprecation, as
well as available alternatives.

Of course, if there are compelling technical reasons why something should
not be deprecated, we can move things into the "Removed from this proposal"
section, in which case it will serve as documentation why some
functionality should not deprecated.

Regards,
Nikita

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

[Hans Henrik Bergan]

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.. make it go E_DEPRECATED in the distant future..


Rowan said "they are commonly used, both correctly and
incorrectly", in my experience, no it's not used correctly, people who are
using it, are using it incorrectly to convert Windows-1252 to utf-8, not
ISO-8859-1...



On Mon, 22 Mar 2021 at 02:15, Sara Golemon  wrote:

> On Sun, Mar 21, 2021 at 9:18 AM Rowan Tommins 
> wrote:
>
> > A) Raise a deprecation notice in 8.1, and remove in 9.0. Do not provide
> > a specific replacement, but recommend people look at iconv() or
> > mb_convert_encoding(). There is precedent for this, such as
> > convert_cyr_string(), but it may frustrate those who are using the
> > functions correctly.
> >
> > B) Introduce new names, such as utf8_to_iso_8859_1 and
> > iso_8859_1_to_utf8; immediately make those the primary names in the
> > manual, with utf8_encode / utf8_decode as aliases. Raise deprecation
> > notices for the old names, either immediately or in some future release.
> > This gives a smoother upgrade path, but commits us to having these
> > functions as outliers in our standard library.
> >
> > C) Leave them alone forever. Treat it as the user's fault if they mess
> > things up by misunderstanding them.
> >
> >
> My preference is for a deprecation notice (but not necessarily removal ever
> -- We can argue that part a little).
>
> As for what users should use instead, obviously there are multiple options
> already in core (which you referenced), but those all have third party deps
> and can't be guaranteed the way utf8_en/decode() can (this was the point of
> moving them from xml).
>
> While I'm normally in favor of userspace things belonging in userspace
> (this particular conversion is trivial since it's a 1:1 mapping), I'm
> actually willing to see this added under a new, clearer name in
> ext/standard since this is something that's in long use, but used
> incorrectly.
>
> As for details, I don't love iso_8859_1_to_utf8(), but we can use the
> common alias for iso-8859-1 known as latin1 and call the new functions:
> utf8_from_latin1() and utf8_to_latin1() with the caveat that the later will
> throw a ValueError for codepoints which are out of range (one of the more
> problematic issues with utf8_decode()).  That makes this not just a simple
> rename for clarity, but what I'd consider a bug-fix for an unfortunately
> unfixable function.
>
> -Sara
>