Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85578
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <F5.C2.06567.5A45A155@pb1.pair.com>
References: <CAF+90c-CbGZ1d3DJSbzPmCbpjm6Pw3qPXQ=CG4XvbaM+528+jQ@mail.gmail.com>
	<5515D57F.9070505@gmail.com>
	<CAF+90c9ZCE4rrdtwoqwnBE=u_s4aSXHU4N_Jia+40OY_gumjaA@mail.gmail.com>
	<F5.C2.06567.5A45A155@pb1.pair.com>
Date: Tue, 31 Mar 2015 15:07:35 +0700
Message-ID: <CAEZPtU44K=rr36Duc3P+nmE7y1OEtCXsi0BWcOOqWjs=VqLkSw@mail.gmail.com>
To: Tony Marston <TonyMarston@hotmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Deprecate or remove mbstring function overloads in PHP 7
From: pierre.php@gmail.com (Pierre Joye)

On Tue, Mar 31, 2015 at 3:02 PM, Tony Marston <TonyMarston@hotmail.com> wrote:
> "Nikita Popov"  wrote in message
> news:CAF+90c9ZCE4rrdtwoqwnBE=u_s4aSXHU4N_Jia+40OY_gumjaA@mail.gmail.com...
>
>>
>> On Fri, Mar 27, 2015 at 11:11 PM, Stanislav Malyshev <smalyshev@gmail.com>
>> wrote:
>>
>>> Hi!
>>>
>>> I was never happy about this particular hack but that said, unless we
>>> *know* it is not used widely (and I suspect it is in Japan etc. where we
>>> don't have a lot of visibility due to language barrier) we can't really
>>> remove it.
>>
>>
>>
>>> Also, I'm not sure why should we remove it. Yes, it's a PITA for the
>>> code, but looking at it in another direction, it is only a PITA if
>>> people actually turn it on, which means they're using it (otherwise why
>>> turn it on?). Deprecating it may be ok provided we actually have some
>>> proposal as to what people should do instead.
>>>
>>> If we have consensus on deprecating it, I don't think it's a problem
>>> have it done in 7.0 since it's not a substantial code/feature change and
>>> beta period provides ample time for people to scream if it's
>>> unacceptable. If there's no consensus yet, I'd go for 7.1.
>>>
>>
>> From this thread, I'd say we have a consensus to deprecate it. From the
>> Japanese side, both Yasuo and Masaki agree that this should be dropped and
>> Masaki also linked a bug report where it is stated that the original
>> author
>> of this functionality agrees that this should be deprecated. It also
>> contains a link to a discussion on a Japanese PHP dev ML, where, as far as
>> Google Translate can tell me, everyone agreed that that we should do away
>> with it.
>>
>> As to what people should use instead: For the quick hack to make things
>> work: a sed script. Apart from that, implementing proper multibyte
>> handling
>> in applications.
>>
>> Nikita
>
>
> But what is "proper" multibyte handling? Where is it documented?

Just to be sure it is clear:

We are not talking about deprecating the mbstring extenson, not at all.

What we refer to is about deprecating the PHP functions overloading in
mbstring. This can be enabled using:

http://php.net/manual/en/mbstring.configuration.php#ini.mbstring.func-overload

and

http://php.net/manual/en/mbstring.overload.php

So far, I know nobody outside the original authors actually using it.
And I asked quite a lot of companies and devs around here (hint,
Asia).

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org