Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73062
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.214.54 as permitted sender)
Message-ID: <531EEE2A.2000602@googlemail.com>
Date: Tue, 11 Mar 2014 12:06:18 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Lester Caine <lester@lsces.co.uk>
CC: PHP Developers Mailing List <internals@lists.php.net>
References: <531EE602.3090207@lsces.co.uk>
In-Reply-To: <531EE602.3090207@lsces.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Unicode strings?
From: cryptocompress@googlemail.com (Crypto Compress)

Hi,

Am 11.03.2014 11:31, schrieb Lester Caine:
> I'm slowly working through a long list of things relating to unicode 
> strings trying to work out just where the main problems are.
>
> The very first problem I hit is ICU's limitation to 32bit string 
> lengths. How does the switch to 64bit string length on 64 bit 
> platforms impinge on this. While I can see the advantage of this 
> particular change, would that also now require our own version of ICU 
> capable of also handling longer strings? This probably falls out in 
> the wash of my next point ...

Where have you found this information? Can you please provide source for 
this?


>
> Currently strings are simply strings? I'm sure we have already had 
> this discussion, and it will be necessary to switch from simple 
> strings to a string object which can handle the intricacies of unicode?

Yes, currently we have so called binary strings (simple bytes, 8 bits).
No, we should not create an string-object to handle all intricacies of 
unicode.


>
> Pierre - I presume that it's this distinction that is where I'm 
> crossing over between variable and similar names which just remain as 
> simple stings while 'data' that is unicode is provided by sting 
> objects. These then need to work nicely with areas that expect a 
> simple string? Where a string object is returned an ASCII version will 
> be created when a simple string is necessary?
>
> The 'leak' of unicode currently into name strings is simply that there 
> is nothing currently stopping them from storing UTF-8? That this works 
> is more by luck than design, but results in subtle problems with case 
> conversion and the like which does not expect unicode strings? BUT 
> people can currently use any format data in a string even one using a 
> 64 bit pointer as long as it does not go through a path that does 
> expect ASCII?
>
> If the simple string is isolated from UTF-8 and unicode is kept to 
> it's own data type such as an improved integrated mbstring package 
> then this make a suitable 'half way' house for PHP6?
>
> I don't NEED unicode variable names, but I can see that this would be 
> a nice to have in non-English speaking countries. In much the same way 
> we provide translated versions of web pages, I can even see the 
> advantage of function name aliases in different languages as having 
> more relevance that simply changing the current English names for 
> picky reasons, but that is not likely to happen in my lifetime! 
> Perhaps PHP10 :)
>

We should not discuss this till Pierre/we clarified the core problems.

cryptocompress