On 15/09/17 12:13, Tony Marston wrote: > My argument is that far too many people have become used to case > insensitive software, and to remove this "feature" for no other reason > than the programmers involved would find it "more convenient" to remove > the feature altogether rather than make the effort in implementing a > proper solution would go down like a ton of bricks with all those users.
case-insensitive only works reliably for an ascii character set. This is what the vast majority of PROGRAMMERS expect to see. Even Microsoft 16bit subset of unicode characters can not RELIABLY be upper or lower cased, but add the full unicode set and the conflicts of the number of characters required for one or other conversion explains why a conversion to unicode in the core proved impractical. The main point here is that it may be ESSENTIAL to introduce a switch to case sensitive if we are also to convert to full unicode support. The alternative is to restrict the character set back to ascii for all programming operations if case-insensitivity is to be retained. And how many of you have hit the problem of Windows supplying a CamelCase version of a file name when it was entered lower case. Since all our web servers are 'non-windows', hitting the idiosyncrasies of these inappropriate case conversions just adds to the fun. That may not the happening these days, but cause major problems at one time! -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
