Re: [RFC] UString
| From: | Yasuo Ohgaki | Date: | Sun, 01 Mar 2015 21:26:05 +0000 |
| Subject: | Re: [RFC] UString | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-84123@lists.php.net to get a copy of this message | ||
Hi Lester,
On Mon, Mar 2, 2015 at 5:34 AM, Lester Caine <lester@lsces.co.uk> wrote:
> On 28/02/15 06:48, Joe Watkins wrote:
> > This is just a quick note to announce my intention to ready this RFC
> > for voting next week.
>
> Since there is nothing in this which needs any changes to the core then
> surly it simply needs to exist in pecl until such time as a proper
> replacement for unicode in core strings has been addressed? Since it
> will still require intl to provide those areas it does not support, and
> I question if we really need to provide yet another encoding converter.
>
> A unicode string handler that just handles UTF8 strings may be yet
> another stepping stone, but it still falls short of beings able to
> handle all of the internationalization problems and is simply an
> alternate to mbstring so one either runs both, or sit down and convert
> all the third party libraries to eliminate mbstring.
>
> Like http extension, it's not essential that it's loaded by default, and
> leaving it in pecl allows development outside that of the core?
Although it seems current code does not have code like GMP. I'm sure
we'll have this before release. i.e.
$new = $some_ustring . 'abc'; // $new is UString object
To implement feature like this, it cannot be PECL.
My only concern for this RFC performance. It's loosely integrated into PHP
core, it may affect efficiency. I suppose other people are working on simple
and tighter integration into core. Any comments on this?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net