Hi,
A definite, -1 for #2, it's a _massive_ BC break with no justification
so far IMHO.
The optimization point is quite moot, tolower could be restricted to
compilation + dynamic accesses, which would remove most of them
already.
OTOH option #1 seems like the most sensible approach, breaking onl
+1 for option #2.
Joël.
On Sun, Apr 18, 2010 at 11:58 PM, Adam Harvey wrote:
> As at least some of you would already be aware, there's a
> long-standing issue with using PHP in a Turkish or Azeri locale,
> namely that case-insensitive lookups within the Zend engine (method
> names, for example)
2010.04.19 07:59 Stan Vassilev rašė:
>>As at least some of you would already be aware, there's a
>>long-standing issue with using PHP in a Turkish or Azeri locale,
>>namely that case-insensitive lookups within the Zend engine (method
>>names, for example) fail on lookups involving upper-case I char
On 19 April 2010 12:59, Stan Vassilev wrote:
> If you ask me, there's only one way to fix this, which is how most other
> languages fixed it: make the next major version of PHP case-sensitive for
> all identifiers. For less bugs, less locale problems and more performance.
Definitely another optio
As at least some of you would already be aware, there's a
long-standing issue with using PHP in a Turkish or Azeri locale,
namely that case-insensitive lookups within the Zend engine (method
names, for example) fail on lookups involving upper-case I characters,
since lower-case I in those language
As at least some of you would already be aware, there's a
long-standing issue with using PHP in a Turkish or Azeri locale,
namely that case-insensitive lookups within the Zend engine (method
names, for example) fail on lookups involving upper-case I characters,
since lower-case I in those languages
