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 frustra
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 ins
On Sun, Mar 21, 2021 at 10:08 PM Kamil Tekiela wrote:
> I think we really do not need to keep these functions. As for the
> alternative that we can offer, iconv seems to be doing exactly the same
> thing and even better. mb_convert_encoding does the same but also silently
> ignores invalid charac
Hi Benjamin,
thanks, in fact I was planning to ask you to open a bug report in order
to reference it in the test files and commit message.
I have the fix ready and it doesn't seem to have side effects on the
existing tests. I'd expect to push it in the coming week, thanks for the
reminder ;-
Option A, please.
I have never had a reason to use either of these two functions. I assume
there's plenty of valid applications for converting between ISO-8859-1 and
UTF-8, but that function causes more harm than good.
I have seen plenty of people use it, but I have never seen anyone use it
proper
On 21/03/2021 16:51, Larry Garfield wrote:
As Rowan notes, what people actually*want* most of the time is "I got this string
from a user and have NFI what it's encoding is, but my system needs UTF-8, so gimmie this
string in UTF-8." And they use utf8_encode(), which then fails*sometimes* in
On Sun, Mar 21, 2021, at 9:18 AM, Rowan Tommins wrote:
> Hi all,
>
> The functions utf8_encode and utf8_decode are historical oddities, which
> almost certainly would not be accepted if proposed today:
>
> * Their names do not describe their functionality, which is to convert
> to/from one spec
> On Mar 21, 2021, at 09:32, Benjamin Morel wrote:
>
> On Sun, 21 Mar 2021 at 15:18, Rowan Tommins wrote:
>
>> I can see three ways forward:
>>
>> 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_co
Thank you for opening this conversation, these functions have stung me
in the past, and I would be so happy to see them gone :)
Personally, I would very much like to go with Plan A.
- XML parsers that often deal with non-UTF-8 character encodings
frequently use these functions. However, any parse
On Sun, 21 Mar 2021 at 15:18, Rowan Tommins wrote:
> I can see three ways forward:
>
> 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_
Hi all,
The functions utf8_encode and utf8_decode are historical oddities, which
almost certainly would not be accepted if proposed today:
* Their names do not describe their functionality, which is to convert
to/from one specific single-byte encoding. This leads to a common
confusion that t
> >> Is there any reason why the pgsql driver doesn't respect PDO::PARAM_STR?
> >
> > Looks like a bug to me. I thought this had been fixed a while back, but
> > apparently it wasn't. I'll try to find some time to investigate in the
> > next few days.
>
> Looks like the problem is in
> <
> https://
Le 20/03/2021 à 02:59, Mike Schinkel a écrit :
- It could make XDEBUG debugging much less tedious by eliminating the
drill-down into the autoloader every time an unloaded class is referenced.
Yes ! I second that, it would be a huge win for a lot of overly
pessimistic developers that do xdebug
13 matches
Mail list logo
