2012/4/22 C.Koy can5...@gmail.com
On 4/21/2012 4:37 AM, Galen Wright-Watson wrote:
What about instead creating a special-purpose Zend function to normalize
class names (zend_normalize_class_name, or zend_classname_tolower)? This
function would examine the current locale and, if it's a problematic one,
convert the string to lower case on its own (calling zend_tolower on
non-problematic characters). Alternatively, zend_normalize_class_name
could
switch LC_CTYPE to an appropriate locale (e.g. UTF-8; the locale could
be
determined at compile time), call zend_str_tolower_copy, then switch back
before returning. Then, any appropriate function (e.g.
zend_resolve_class_name, zend_lookup_class_ex, class_exists, class_alias)
would call zend_normalize_class_name instead of zend_str_tolower_copy/
zend_str_tolower_dup.
In plain words/pseudo-code, adding an if statement at a certain step
should suffice, like:
1. lowercase the name;
2. if the effective locale is tr_XY, then replace every ı with i;
3. look up the name;
For those who have nothing to do with Turkish locales, that should incur
the overhead of an if condition only.
The fix would need to be applied to at least four functions, so adding a
new function would be more maintainable. Also, there are locales that don't
begin with tr_ or have TR in the locale name, so the condition would
need to be more complex.
Converting I or ı separately from lowercase conversion is less
performant than either option I describe, as it requires an extra loop,
which is why I didn't bother suggesting it. I suspect switching the locale
is most performant, as it doesn't require additional tests, though I
haven't examined the cost of setting the locale.
But, I did not start this thread to discuss such bug fix, because:
1. It does not take a genius to figure it out, and should take minutes to
implement for someone experienced in the internals. Given the 10 year span
and dozens of comments/complaints on the bug's entry, it's hard to say this
issue went unnoticed. So I had to conclude that such fix has quietly been
overruled for performance and/or other undisclosed reasons.
Why does it matter if a solution is simple? If anything, that a fix does
not take a genius is an argument in its favor, if it also solves the
problem.
If it's already been rejected privately, it's time to bring the reasons
into the open (which is why I asked). If not, it should be considered
publicly.
2. Absent bug #18556, case-sensitive PHP has merits as I stated in other
post and several people voiced opinions in favor. Case-sensitive PHP is
worth considering.
It is, but it's also a major BC break, hence perhaps better suited for
PHP6. Case-sensitivity is also a much bigger issue than this bug. A custom
conversion function, on the other hand, produces the minimum impact of any
option I've read. As such, it's hopefully a solution for this bug that
everyone can agree on.
Does this bug pop-up for locales other than Turkish, Azerbaijani and
Kurdish
?
Theoretically, this problem occurs for any locales sharing a letter
lowercase of which is different from each other's, and the PHP script
changes its locale among these locales throughout its execution.
The abstract property that makes a locale problematic is obvious. I was
looking for specific locales, as they need to be identified for a complete
solution.
