On Thu, Dec 25, 2014 at 04:40:09AM +0100, François Laupretre wrote: > > He will also have to deal with > > file ops while being at it. Should they remain case insensitive? Do > > manual checks to match the path actually being requested (ie. possible > > on windows using meta info), or keep everything the way it is now? > > Do you mean simulating case-sensitive paths on case-insensitive file systems > ? Why not, depending on the overhead it brings. Unfortunately, I don't have > the Windows skills required to work on the subject. > > About the overhead the check introduces, note that it is supposed to be > temporary. The final goal is to store symbols as-Is, eliminating the need for > lowercase conversions. This would remove a lot of allocations and calls to > zend_str_tolower_copy(). This would also remove a lot of code.
I see case (in)sensetivity in names of functions/classes/... as being separate from case sensetivity in file names. There is already a problem for those who develop on MS-Windows/Mac and deploy on *nix - a typeo can lead to a failure at run time. The fix is simple, people do not complain that PHP should protect them from this. I am a believer in simplicity, which is part of the reason that I support the idea of removing the complexity of case insensitivity in function/... names. Case folding has a slight speed penalty and does not work properly. It does not fold unicode characters outside the range U+40 - U+7A (ie US ASCII), so best to just forget it. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include <std_disclaimer.h> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
