Re: [VOTE] RFC: Multibyte Char Handling
From: Christopher Jones Date: Tue, 28 Jan 2014 20:24:55 +0000 Subject: Re: [VOTE] RFC: Multibyte Char Handling References: 1 2 3 4 5 6 7 Groups: php.internals Request: Send a blank email to [email protected] to get a copy of this message
On 01/26/2014 06:53 PM, Yasuo Ohgaki wrote:Hi Dan, On Mon, Jan 27, 2014 at 9:09 AM, Yasuo Ohgaki <[email protected]> wrote:Since this RFC (https://wiki.php.net/rfc/multibyte_char_handling) depends on another unfinalized one (https://wiki.php.net/rfc/altmbstring), surely it is too premature to be voting on https://wiki.php.net/rfc/multibyte_char_handling now? The situation is just confusing and counter productive. I quote from the RFC:I just didn't want to touch 5 year old RFC. As I wrote in parent RFC, the implementation is subject to be changed.I've updated altmbstring RFC as this RFC name implies. Original author was intended to provide alternative to mbstring. In contrast, my RFC is intended to replace mbstring by mbstring-ng. There are technical difficulties to copy all of mbstring feature to mbstring-ng, we may evaluate them and decide migration procedure when mbstring-ng is ready. Choices would be - provide mbstring-ng as alternative of mbstring- keep mbstring-ng in php-src, move mbstring to PECL - keep both mbstring-ng and mbstring in php-src- replace mbstring by mbstring-ng and move mbstring to PECL as mbstring-legacy. I'm not sure which one is the best. We may try to find out by providing mbstring-ng as EXPERIMENTAL module. Regards, -- Yasuo Ohgaki [email protected]Compile mbstringp-ng as default compiled module, when mbstring-ng is ready. See following FRC [sic] for mbstring-ng details.Alternative implementation of mbstring using ICU [the previous sentence is a link to https://wiki.php.net/rfc/altmbstring]Until mbstring-ng is ready, mbstring-ng is provided as EXPERIMENTAL module.mbstring-ng implementation is subject to be changed.Chris P.S. Am I the only one getting confused by a plethora of RFCs and ideas and last minute changes? If an RFC is changed materially, then the vote should be stopped and restarted after an appropriate time for discussion. P.P.S. Some confusion could be avoided if the second part of #18 (about including the URL in emails) was followed from: https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process This is a common issue with RFC discussions on internals. -- [email protected] http://twitter.com/ghrd Free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
Thread (20 messages)
| « previous | php.internals (#71697) | next » |
|---|