Hi! > If they were truly case-insensitive, I might agree. However, as I've > mentioned but will reiterate, they're not. They're ASCII case > insensitive, and that's a long cry from real case-insensitivity. PHP > 6 was planning to make case-insensitivity real but obviously that's > dead and buried.
Should we really go there then? Full Unicode support for these things is probably not going to happen, and I'd argue not many people actually need it. Like it or not, it is not super-common to write PHP function names or constant names in Russian, Farsi or hiragana. It demoes nice, but I'm not sure that is a primary feature people would seek. > This is ugly, but if I'm playing devil's advocate, it is consistent > with the rest of the core runtime. Frankly, I'd be fine with either - provided that we don't have more than one kind (i.e. if we allow case-insensitive constants, no defining both FOO and Foo). But for cases-sensitivity I am worried about BC impact. We do have a bunch of CI constants in extensions, including such widely used modules as mcrypt. I'm not sure people use it in different cases, but hard to really know... Maybe with suitable deprecation step it'd be OK, but not sure how to make it work for CI constants. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
