Re: [PHP-DEV] Re: Turkish/Azeri locale support
Hi! Change to 100% case-insensitive function names has bigger probability of BC break. I think I've seen code which used functions in a way that It's not a probability, it's a certainty. There's tons of code out there (I'm sure including 99% of all popular apps and frameworks) that uses different cases somehow somewhere). If there was no BC issue, I'd definitely be for case-sensitive names, but with BC it may become kind of tricky... -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Turkish/Azeri locale support
Pierre Joye wrote: On Tue, May 4, 2010 at 2:14 PM, Adam Harvey wrote: 1. Apply Tomas's patch to make case-insensitive lookups locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for case-insensitive function/method name lookups for high-bit characters in single-byte encodings. (Not that we've ever advertised or documented that.) 2. Make function/method names case-sensitive, per Stan's e-mail. Pros: fixes problem; brings PHP into line with most other languages; extra consistency with variables; possible performance improvement. Cons: BC break from current documented behaviour. 3. Do nothing. Pros: no BC breaks of any kind. Cons: continues to annoy Turkish and Azeri developers and those developing for those locales. I don't think that option 2 and 3 can be done in 5.x. However I'm +1 for option 2 in PHP 6 (whenever it comes). Cheers, As Lukas clearly stated, case sensivity is not an option for PHP 5.4 so I was voting for option 2 in PHP6 anyway :) -- Steven
Re: [PHP-DEV] Re: Turkish/Azeri locale support
Zitat von Adam Harvey : Well, I'm going to assume that people have had whatever say they were going to. It seems that we have three options, so let's put it to a vote. +1 for option 1. Unless we can have some aliases to fix the problem with some PHP functions being documented non-all-lower-case, like the GD functions mentioned earlier in the thread. In that case: +1 for 2. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Turkish/Azeri locale support
On 5 May 2010 12:16, Adam Harvey wrote:
> On 5 May 2010 19:01, Steven Van Poeck wrote:
>> Right. That's what I meant by inconsistent code. The call
>> $logs->getSQLLogger()->logSql("...") would function I presume.
>> The reason your example code does not is because it is inconsistent. You're
>> calling $logs->getSqlLogger() instead of $logs->getSQLLogger()
>
> Agreed, but not everyone's going to spot that first time, particularly
> the sorts of newer programmers we get quite a lot of writing PHP.
> Also, the error message you get out the other end is suboptimal, to
> say the least.
>
> I've been holding out on stating my reasoning much beyond my initial
> post and vote to try avoiding influencing anyone, but I'm opinionated,
> so here goes. :)
>
> Here's an example of my problem with enforcing case-sensitivity in
> general that builds on something Johannes said yesterday on IRC: how
> many people use different cases for the gd functions? Taking, say,
> imagestring as a simple example and having a quick look at Google Code
> Search, the variants people are using there are:
>
> ImageString: about 3000 results [0]
> imagestring: about 4000 results [1]
> imageString: 453 results [2]
> IMAGESTRING: 1 result [3]
>
> There are probably other variations in use too, and that's one of the
> more simply named functions in gd.
>
> The above example pretty much sums up why I went for option 1 instead
> of 2 in my vote: it's still a BC break, but I honestly thing it's
> going to be a much more minor break (remember, it only affects people
> in certain Western European locales such as French, Spanish and German
> who are _also_ using single-byte encodings — most Linux distros I know
> of are shipping with UTF-8 as a default, so they're already
> effectively case-sensitive for non-ASCII characters) than changing the
> entire language and probably causing issues in a wide variety of
> applications.
>
> If I was designing the language anew, sure, I'd go for
> case-sensitivity the whole way, but as things stand, I'm pretty
> dubious it would work out.
>
> Adam
>
> [0]
> http://www.google.com.au/codesearch?as_q=%22ImageString%22&btnG=Search+Code&hl=en&as_lang=php&as_license_restrict=i&as_license=&as_package=&as_filename=&as_case=y
> [1]
> http://www.google.com.au/codesearch?as_q=imagestring&btnG=Search+Code&hl=en&as_lang=php&as_license_restrict=i&as_license=&as_package=&as_filename=&as_case=y
> [2]
> http://www.google.com.au/codesearch?as_q=imageString&btnG=Search+Code&hl=en&as_lang=php&as_license_restrict=i&as_license=&as_package=&as_filename=&as_case=y
> [3]
> http://www.google.com.au/codesearch?as_q=IMAGESTRING&btnG=Search+Code&hl=en&as_lang=php&as_license_restrict=i&as_license=&as_package=&as_filename=&as_case=y
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
_IF_ case sensitivity is going to be incorporated and the BC is too
great, is the following an option.
1 - Introduce case sensitivity with an option to allow a fallback to
the existing mechanism.
2 - Generate an E_NOTICE or an E_STRICT to inform developers/users of the issue.
3 - Stick with the fallback for a while until it is removed
(introduced in 5.x then drop in 7.x).
Alternatively, only activate case sensitivity if E_STRICT is set. If a
developer is creating E_STRICT code, I doubt that they are sloppy with
their case.
E_STRICT is documented as "Enable to have PHP suggest changes to your
code which will ensure the best interoperability and forward
compatibility of your code.". Which seems a perfect fit.
--
-
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Turkish/Azeri locale support
On Wed, May 5, 2010 at 1:20 PM, Pierre Joye wrote: > I don't think that option 2 and 3 can be done in 5.x. However I'm +1 > for option 2 in PHP 6 (whenever it comes). I meant option 1 and 2. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Turkish/Azeri locale support
On Tue, May 4, 2010 at 2:14 PM, Adam Harvey wrote: > 1. Apply Tomas's patch to make case-insensitive lookups > locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for > case-insensitive function/method name lookups for high-bit characters > in single-byte encodings. (Not that we've ever advertised or > documented that.) > > 2. Make function/method names case-sensitive, per Stan's e-mail. Pros: > fixes problem; brings PHP into line with most other languages; extra > consistency with variables; possible performance improvement. Cons: BC > break from current documented behaviour. > > 3. Do nothing. Pros: no BC breaks of any kind. Cons: continues to > annoy Turkish and Azeri developers and those developing for those > locales. I don't think that option 2 and 3 can be done in 5.x. However I'm +1 for option 2 in PHP 6 (whenever it comes). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Turkish/Azeri locale support
On 5 May 2010 19:01, Steven Van Poeck wrote:
> Right. That's what I meant by inconsistent code. The call
> $logs->getSQLLogger()->logSql("...") would function I presume.
> The reason your example code does not is because it is inconsistent. You're
> calling $logs->getSqlLogger() instead of $logs->getSQLLogger()
Agreed, but not everyone's going to spot that first time, particularly
the sorts of newer programmers we get quite a lot of writing PHP.
Also, the error message you get out the other end is suboptimal, to
say the least.
I've been holding out on stating my reasoning much beyond my initial
post and vote to try avoiding influencing anyone, but I'm opinionated,
so here goes. :)
Here's an example of my problem with enforcing case-sensitivity in
general that builds on something Johannes said yesterday on IRC: how
many people use different cases for the gd functions? Taking, say,
imagestring as a simple example and having a quick look at Google Code
Search, the variants people are using there are:
ImageString: about 3000 results [0]
imagestring: about 4000 results [1]
imageString: 453 results [2]
IMAGESTRING: 1 result [3]
There are probably other variations in use too, and that's one of the
more simply named functions in gd.
The above example pretty much sums up why I went for option 1 instead
of 2 in my vote: it's still a BC break, but I honestly thing it's
going to be a much more minor break (remember, it only affects people
in certain Western European locales such as French, Spanish and German
who are _also_ using single-byte encodings — most Linux distros I know
of are shipping with UTF-8 as a default, so they're already
effectively case-sensitive for non-ASCII characters) than changing the
entire language and probably causing issues in a wide variety of
applications.
If I was designing the language anew, sure, I'd go for
case-sensitivity the whole way, but as things stand, I'm pretty
dubious it would work out.
Adam
[0]
http://www.google.com.au/codesearch?as_q=%22ImageString%22&btnG=Search+Code&hl=en&as_lang=php&as_license_restrict=i&as_license=&as_package=&as_filename=&as_case=y
[1]
http://www.google.com.au/codesearch?as_q=imagestring&btnG=Search+Code&hl=en&as_lang=php&as_license_restrict=i&as_license=&as_package=&as_filename=&as_case=y
[2]
http://www.google.com.au/codesearch?as_q=imageString&btnG=Search+Code&hl=en&as_lang=php&as_license_restrict=i&as_license=&as_package=&as_filename=&as_case=y
[3]
http://www.google.com.au/codesearch?as_q=IMAGESTRING&btnG=Search+Code&hl=en&as_lang=php&as_license_restrict=i&as_license=&as_package=&as_filename=&as_case=y
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Turkish/Azeri locale support
Hannes Magnusson wrote:
On Wed, May 5, 2010 at 11:41, Steven Van Poeck wrote:
Hannes Magnusson wrote:
2. Make function/method names case-sensitive, per Stan's e-mail. Pros:
fixes problem; brings PHP into line with most other languages; extra
consistency with variables; possible performance improvement. Cons: BC
break from current documented behaviour.
There is no way this can happen. It will break massive amount of code
and will cause major headaches for people using __call().
-Hannes
Can you give an example of *consistent* code where this evolution would
cause __call() not to function properly ? I'm afraid I can't think of any...
Can you give an example of *consistent* code? Just any. Any at all.
Doesn't have to be long.
class Logs {
function getSQLLogger() {
return $this->logs["sql"];
}
function __call() {
return $this->logs["default"];
}
}
$logs->getSqlLogger()->logSql("...");
..call to undefined method default::logSql()...
-Hannes
Right. That's what I meant by inconsistent code. The call
$logs->getSQLLogger()->logSql("...") would function I presume.
The reason your example code does not is because it is inconsistent.
You're calling $logs->getSqlLogger() instead of $logs->getSQLLogger()
Or am I missing your point ?
--
Steven
Re: [PHP-DEV] Re: Turkish/Azeri locale support
On Wed, May 5, 2010 at 11:41, Steven Van Poeck wrote:
> Hannes Magnusson wrote:
>
> 2. Make function/method names case-sensitive, per Stan's e-mail. Pros:
> fixes problem; brings PHP into line with most other languages; extra
> consistency with variables; possible performance improvement. Cons: BC
> break from current documented behaviour.
>
>
> There is no way this can happen. It will break massive amount of code
> and will cause major headaches for people using __call().
>
> -Hannes
>
>
>
> Can you give an example of *consistent* code where this evolution would
> cause __call() not to function properly ? I'm afraid I can't think of any...
Can you give an example of *consistent* code? Just any. Any at all.
Doesn't have to be long.
class Logs {
function getSQLLogger() {
return $this->logs["sql"];
}
function __call() {
return $this->logs["default"];
}
}
$logs->getSqlLogger()->logSql("...");
..call to undefined method default::logSql()...
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Turkish/Azeri locale support
Hannes Magnusson wrote: 2. Make function/method names case-sensitive, per Stan's e-mail. Pros: fixes problem; brings PHP into line with most other languages; extra consistency with variables; possible performance improvement. Cons: BC break from current documented behaviour. There is no way this can happen. It will break massive amount of code and will cause major headaches for people using __call(). -Hannes Can you give an example of *consistent* code where this evolution would cause __call() not to function properly ? I'm afraid I can't think of any... Steven
Re: [PHP-DEV] Re: Turkish/Azeri locale support
On 05.05.2010, at 08:44, Patrick ALLAERT wrote: > 2010/5/4 Adam Harvey : >> On 19 April 2010 11:58, 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) fail on lookups involving upper-case I characters, >>> since lower-case I in those languages is ı instead of i (note the lack >>> of a dot). >> >> Well, I'm going to assume that people have had whatever say they were >> going to. It seems that we have three options, so let's put it to a >> vote. >> >> (To be completely clear, this is purely for trunk. This certainly >> isn't a candidate for backporting to 5.3.) >> >> The options are: >> >> 1. Apply Tomas's patch to make case-insensitive lookups >> locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for >> case-insensitive function/method name lookups for high-bit characters >> in single-byte encodings. (Not that we've ever advertised or >> documented that.) >> >> 2. Make function/method names case-sensitive, per Stan's e-mail. Pros: >> fixes problem; brings PHP into line with most other languages; extra >> consistency with variables; possible performance improvement. Cons: BC >> break from current documented behaviour. > > Once and for all: +1 for #2 (BTW that kind of BC will not be that hard to > fix!) we have had the topic of making PHP case sensitive before. I do not find the above reason all that compelling to make this change. However there are several other reasons that imho are more relevant for making this change. > RMs: should this really be part of PHP 5.4 if it gets approved? no way. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Turkish/Azeri locale support
On Tue, May 4, 2010 at 14:14, Adam Harvey wrote: > On 19 April 2010 11:58, 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) fail on lookups involving upper-case I characters, >> since lower-case I in those languages is ı instead of i (note the lack >> of a dot). > > Well, I'm going to assume that people have had whatever say they were > going to. It seems that we have three options, so let's put it to a > vote. > > (To be completely clear, this is purely for trunk. This certainly > isn't a candidate for backporting to 5.3.) > > The options are: > > 1. Apply Tomas's patch to make case-insensitive lookups > locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for > case-insensitive function/method name lookups for high-bit characters > in single-byte encodings. (Not that we've ever advertised or > documented that.) +1 > 2. Make function/method names case-sensitive, per Stan's e-mail. Pros: > fixes problem; brings PHP into line with most other languages; extra > consistency with variables; possible performance improvement. Cons: BC > break from current documented behaviour. There is no way this can happen. It will break massive amount of code and will cause major headaches for people using __call(). -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Turkish/Azeri locale support
> -Original Message- > From: a...@adamharvey.name [mailto:a...@adamharvey.name] On Behalf > Of Adam Harvey > Sent: 04 May 2010 13:15 > The options are: > > 1. Apply Tomas's patch to make case-insensitive lookups > locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for > case-insensitive function/method name lookups for high-bit > characters > in single-byte encodings. (Not that we've ever advertised or > documented that.) > > 2. Make function/method names case-sensitive, per Stan's e-mail. > Pros: > fixes problem; brings PHP into line with most other languages; extra > consistency with variables; possible performance improvement. Cons: > BC > break from current documented behaviour. > > 3. Do nothing. Pros: no BC breaks of any kind. Cons: continues to > annoy Turkish and Azeri developers and those developing for those > locales. Low karma here, too, but for what it's worth I'm for option 2. (I can never remember what's case sensitive and what's not, so I always write code that would work either way anyway!) Cheers! Mike -- Mike Ford, Electronic Information Developer, Libraries and Learning Innovation, Leeds Metropolitan University, C507, Civic Quarter Campus, Woodhouse Lane, LEEDS, LS1 3HE, United Kingdom Email: m.f...@leedsmet.ac.uk Tel: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm
Re: [PHP-DEV] Re: Turkish/Azeri locale support
On Wed, May 5, 2010 at 8:44 AM, Patrick ALLAERT wrote: > 2010/5/4 Adam Harvey : > > On 19 April 2010 11:58, 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) fail on lookups involving upper-case I characters, > >> since lower-case I in those languages is ı instead of i (note the lack > >> of a dot). > > > > Well, I'm going to assume that people have had whatever say they were > > going to. It seems that we have three options, so let's put it to a > > vote. > > > > (To be completely clear, this is purely for trunk. This certainly > > isn't a candidate for backporting to 5.3.) > > > > The options are: > > > > 1. Apply Tomas's patch to make case-insensitive lookups > > locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for > > case-insensitive function/method name lookups for high-bit characters > > in single-byte encodings. (Not that we've ever advertised or > > documented that.) > > > > 2. Make function/method names case-sensitive, per Stan's e-mail. Pros: > > fixes problem; brings PHP into line with most other languages; extra > > consistency with variables; possible performance improvement. Cons: BC > > break from current documented behaviour. > > Once and for all: +1 for #2 (BTW that kind of BC will not be that hard to > fix!) > > RMs: should this really be part of PHP 5.4 if it gets approved? > AFAIK the new stable branch version number hasn't been decided yet. Tyrael
Re: [PHP-DEV] Re: Turkish/Azeri locale support
2010/5/4 Adam Harvey : > On 19 April 2010 11:58, 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) fail on lookups involving upper-case I characters, >> since lower-case I in those languages is ı instead of i (note the lack >> of a dot). > > Well, I'm going to assume that people have had whatever say they were > going to. It seems that we have three options, so let's put it to a > vote. > > (To be completely clear, this is purely for trunk. This certainly > isn't a candidate for backporting to 5.3.) > > The options are: > > 1. Apply Tomas's patch to make case-insensitive lookups > locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for > case-insensitive function/method name lookups for high-bit characters > in single-byte encodings. (Not that we've ever advertised or > documented that.) > > 2. Make function/method names case-sensitive, per Stan's e-mail. Pros: > fixes problem; brings PHP into line with most other languages; extra > consistency with variables; possible performance improvement. Cons: BC > break from current documented behaviour. Once and for all: +1 for #2 (BTW that kind of BC will not be that hard to fix!) RMs: should this really be part of PHP 5.4 if it gets approved? > 3. Do nothing. Pros: no BC breaks of any kind. Cons: continues to > annoy Turkish and Azeri developers and those developing for those > locales. > > If you'd care to reply with a vote for option 1, 2 or 3, I'll tally up > the votes in a week or so. And yes, I am volunteering to deal with > this should option 1 or 2 be picked. > > Adam > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Turkish/Azeri locale support
I have low karma, but: +1 for option #2 On 5/4/10 5:14 AM, "Adam Harvey" wrote: > On 19 April 2010 11:58, 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) fail on lookups involving upper-case I characters, >> > since lower-case I in those languages is instead of i (note the lack >> > of a dot). > > Well, I'm going to assume that people have had whatever say they were > going to. It seems that we have three options, so let's put it to a > vote. > > (To be completely clear, this is purely for trunk. This certainly > isn't a candidate for backporting to 5.3.) > > The options are: > > 1. Apply Tomas's patch to make case-insensitive lookups > locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for > case-insensitive function/method name lookups for high-bit characters > in single-byte encodings. (Not that we've ever advertised or > documented that.) > > 2. Make function/method names case-sensitive, per Stan's e-mail. Pros: > fixes problem; brings PHP into line with most other languages; extra > consistency with variables; possible performance improvement. Cons: BC > break from current documented behaviour. > > 3. Do nothing. Pros: no BC breaks of any kind. Cons: continues to > annoy Turkish and Azeri developers and those developing for those > locales. > > If you'd care to reply with a vote for option 1, 2 or 3, I'll tally up > the votes in a week or so. And yes, I am volunteering to deal with > this should option 1 or 2 be picked. > > Adam > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Turkish/Azeri locale support
2010.05.04 20:20 Tomas Kuliavas rašė: > 2010.05.04 17:56 Derick Rethans rašė: >> On Tue, 4 May 2010, Adam Harvey wrote: >> >>> The options are: >>> >>> 1. Apply Tomas's patch to make case-insensitive lookups >>> locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for >>> case-insensitive function/method name lookups for high-bit characters >>> in single-byte encodings. (Not that we've ever advertised or >>> documented that.) >> >> People *do* do this though. >> >> I'm for option 2. > > Change to 100% case-insensitive function names has bigger probability of > BC break. typo. it is "100% case sensitive function names". I think code in question is related to strcasecmp() or some other standard PHP string function. Make sure that you don't break other case insensitive functions, if you go with option two. -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Turkish/Azeri locale support
2010.05.04 17:56 Derick Rethans rašė: > On Tue, 4 May 2010, Adam Harvey wrote: > >> The options are: >> >> 1. Apply Tomas's patch to make case-insensitive lookups >> locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for >> case-insensitive function/method name lookups for high-bit characters >> in single-byte encodings. (Not that we've ever advertised or >> documented that.) > > People *do* do this though. > > I'm for option 2. Change to 100% case-insensitive function names has bigger probability of BC break. I think I've seen code which used functions in a way that depended on case insensitive lookups and same code had problems with Turkish, because case insensitive dependency was only on latin I. Option 1 maintains BC for ascii names. high bit characters don't break only in some locales. You will be lucky until you hit something in 0xC0-0xDF range that does not have direct match in 0xE0-0xFF range, you will enter minefield, if you use 0x80-0xBF and code will be hosed when locale does not support any usual iso-8859-1 high-bit characters matching. -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Turkish/Azeri locale support
On Tue, 4 May 2010, Adam Harvey wrote: > The options are: > > 1. Apply Tomas's patch to make case-insensitive lookups > locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for > case-insensitive function/method name lookups for high-bit characters > in single-byte encodings. (Not that we've ever advertised or > documented that.) People *do* do this though. I'm for option 2. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Turkish/Azeri locale support
On Tue, May 4, 2010 at 2:14 PM, Adam Harvey wrote: > On 19 April 2010 11:58, 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) fail on lookups involving upper-case I characters, > > since lower-case I in those languages is ı instead of i (note the lack > > of a dot). > > Well, I'm going to assume that people have had whatever say they were > going to. It seems that we have three options, so let's put it to a > vote. > > (To be completely clear, this is purely for trunk. This certainly > isn't a candidate for backporting to 5.3.) > > The options are: > > 1. Apply Tomas's patch to make case-insensitive lookups > locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for > case-insensitive function/method name lookups for high-bit characters > in single-byte encodings. (Not that we've ever advertised or > documented that.) > > 2. Make function/method names case-sensitive, per Stan's e-mail. Pros: > fixes problem; brings PHP into line with most other languages; extra > consistency with variables; possible performance improvement. Cons: BC > break from current documented behaviour. > > 3. Do nothing. Pros: no BC breaks of any kind. Cons: continues to > annoy Turkish and Azeri developers and those developing for those > locales. > > If you'd care to reply with a vote for option 1, 2 or 3, I'll tally up > the votes in a week or so. And yes, I am volunteering to deal with > this should option 1 or 2 be picked. > > Adam > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > +1 for the 2nd option. Tyrael
Re: [PHP-DEV] Re: Turkish/Azeri locale support
On 4 May 2010 13:14, Adam Harvey wrote: > The options are: > > 1. Apply Tomas's patch to make case-insensitive lookups > locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for > case-insensitive function/method name lookups for high-bit characters > in single-byte encodings. (Not that we've ever advertised or > documented that.) > > 2. Make function/method names case-sensitive, per Stan's e-mail. Pros: > fixes problem; brings PHP into line with most other languages; extra > consistency with variables; possible performance improvement. Cons: BC > break from current documented behaviour. > > 3. Do nothing. Pros: no BC breaks of any kind. Cons: continues to > annoy Turkish and Azeri developers and those developing for those > locales. +1 for Option 2. Coming from languages where are case sensitive it has never occurred to me that PHP wasn't case sensitive. So no BC for at least 1 user! -- - Richard Quadling "Standing on the shoulders of some very clever giants!" EE : http://www.experts-exchange.com/M_248814.html EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Turkish/Azeri locale support
On 04.05.2010, at 16:44, Steven Van Poeck wrote: > Adam Harvey wrote: >> Well, I'm going to assume that people have had whatever say they were >> going to. It seems that we have three options, so let's put it to a >> vote. >> >> (To be completely clear, this is purely for trunk. This certainly >> isn't a candidate for backporting to 5.3.) >> >> The options are: >> >> 1. Apply Tomas's patch to make case-insensitive lookups >> locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for >> case-insensitive function/method name lookups for high-bit characters >> in single-byte encodings. (Not that we've ever advertised or >> documented that.) >> >> 2. Make function/method names case-sensitive, per Stan's e-mail. Pros: >> fixes problem; brings PHP into line with most other languages; extra >> consistency with variables; possible performance improvement. Cons: BC >> break from current documented behaviour. >> >> 3. Do nothing. Pros: no BC breaks of any kind. Cons: continues to >> annoy Turkish and Azeri developers and those developing for those >> locales. >> >> If you'd care to reply with a vote for option 1, 2 or 3, I'll tally up >> the votes in a week or so. And yes, I am volunteering to deal with >> this should option 1 or 2 be picked. my vote: option 2 that's the most consistent solution -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Turkish/Azeri locale support
Adam Harvey wrote: On 19 April 2010 11:58, 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) fail on lookups involving upper-case I characters, since lower-case I in those languages is ı instead of i (note the lack of a dot). Well, I'm going to assume that people have had whatever say they were going to. It seems that we have three options, so let's put it to a vote. (To be completely clear, this is purely for trunk. This certainly isn't a candidate for backporting to 5.3.) The options are: 1. Apply Tomas's patch to make case-insensitive lookups locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for case-insensitive function/method name lookups for high-bit characters in single-byte encodings. (Not that we've ever advertised or documented that.) 2. Make function/method names case-sensitive, per Stan's e-mail. Pros: fixes problem; brings PHP into line with most other languages; extra consistency with variables; possible performance improvement. Cons: BC break from current documented behaviour. 3. Do nothing. Pros: no BC breaks of any kind. Cons: continues to annoy Turkish and Azeri developers and those developing for those locales. If you'd care to reply with a vote for option 1, 2 or 3, I'll tally up the votes in a week or so. And yes, I am volunteering to deal with this should option 1 or 2 be picked. Adam No idea if I have the right to vote, but here goes: +1 for option 2 BR, Steven
