Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71217
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.46 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CAGa2bXaUsKvf6JCqO287ShDLGEntHyvfAjxYVaGaci0zOWEWvQ@mail.gmail.com>
References: <CAGa2bXauxj6Sca8qYk2cxQ=TeG4bjWgcv-Aqy3cJe35ap72Yfw@mail.gmail.com>
 <CAF+90c-ZgsCczU71TJap1yeaNhKgQeoUR5oLKwwHHaoOD8z_ig@mail.gmail.com>
 <CAGa2bXb6jLX8HMN-rL7t5j5R_0SaeRkd5r4_MrmQFfsJxxaSxQ@mail.gmail.com>
 <1389976678.2057.8.camel@smugmug> <CAMUwpuRU3S3-BHGTAY5W1Jx+iTkT4QxQfV4ZoB6gMHk5EGXTrg@mail.gmail.com>
 <CAGa2bXZ_wjV-S98k5FeYKEAEPA_FMoZgxvWW8QB_QNh2s=1=ow@mail.gmail.com>
 <CAMUwpuSDAo4ee6dy1uribO40RDTJJvhLzz3Z1z3f9h3tqPedrA@mail.gmail.com> <CAGa2bXaUsKvf6JCqO287ShDLGEntHyvfAjxYVaGaci0zOWEWvQ@mail.gmail.com>
Date: Sat, 18 Jan 2014 00:04:05 +0100
Message-ID: <CAMUwpuQok4VcmBFopiSd36JXkbw7mg8P0KzKWZjcQ_EWQFWHbA@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Mike <mike.php.net@gmail.com>, Nikita Popov <nikita.ppv@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [RFC] Multibyte char handling
From: jpauli@php.net (Julien Pauli)

On Fri, Jan 17, 2014 at 11:10 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> Hi Julien,
>
> On Sat, Jan 18, 2014 at 6:50 AM, Julien Pauli <jpauli@php.net> wrote:
>>
>> On Fri, Jan 17, 2014 at 10:34 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>> > Hi all,
>> >
>> > On Sat, Jan 18, 2014 at 5:06 AM, Julien Pauli <jpauli@php.net> wrote:
>> >>
>> >> Like everybody, I' absolutely against adding an "encoding" parameter
>> >> to ext/standard functions or relying on unreliable system locale.
>> >> Like Nikita says, every multibyte function should go to ext/mbstring ,
>> >> and nowhere else, please , do not turn PHP into something even more
>> >> dirty as it is nowadays :-p
>> >>
>> >> I'm +1 to embed and activate mbstring by default in future PHP
>> >> releases.
>> >> However, this has already been discussed (from what I remember) and I
>> >> dont remember why we ended with a "no" end-word, could we be refreshed
>> >> about this ?
>> >>
>> >> I'm not in favor of magic things. Magically replacing PHP strings by
>> >> mb_ implementation is a really bad idea. We should keep the INI
>> >> parameter about this alive though (mbstring.func_overload), so that
>> >> people that explicitely want to activate such a magic can do it if
>> >> they want to.
>> >>
>> >> I'm +1 also to start a "serious" (hum) discussion about multibyte/PHP6
>> >> , we've been saying this for years : we need native support of unicode
>> >> in PHP :-p The actual problem we are facing once again shows this.
>> >
>> >
>> > It seem this is the majority excluding INI usage.
>> > I updated the RFC to reflect this.
>> >
>> > https://wiki.php.net/rfc/multibyte_char_handling
>> >
>> >  - Compile mbstring by default from 5.6
>> >  - Add mb_*() functions for 5.3 and up
>> >  - Keep ext/standard function as it is now
>> >
>> > Open Issue
>> >  - Use of INI for overriding single byte string functions by mbstring
>> > functions.
>>
>> Why is that an issue ?
>> We just leave it as-is , or ?
>
>
> Some users are annoyed by sloppy multilingual implementations using
> this option. There is feature request from user who want to remove
> mbstring.func_overload INI option.
>
> https://bugs.php.net/bug.php?id=65785
>
> We may extend or drop this feature. I neutral for this.

Yep, I admit that lots of people misconfigure it and that make PITA of
developers that always have to test its value.


Julien.P