At 09:06 PM 2/8/2002 +0900, Yasuo Ohgaki wrote: >Marko Karppinen wrote: >>Yasuo: >> >>>Hmm. I vote -1 for this. >>>It just does not make sense to store original(case sensitive) >>>names while langage ignores case. It's also confusing, lead >>>to case sensitivity BC problem anyway just like with case >>>sensitive function/names. >>Case preservation makes very much sense in a case-insensitive environment. >>Just look at file system implementations from Apple and Microsoft, where, >>believe it or not, a lot of thought has gone into this issue. >>I had a private chat with Jason Greene about this, and I came out with the >>understanding that the .NET/SOAP interop issues mentioned here earlier by >>Markus and Jason are actually issues with PHP not preserving case rather >>than with PHP not being fully case-sensitive. > >It will be confusing PHP preserve case for other while >internally case insensitve... > >Therefore, -1 for this :)
It won't be confusing. You are just -1 because you want case sensitivity. How will it confuse you? The only thing it will allow is to support interoperability. It wouldn't confuse people writing PHP code. I don't mind you being against case insensitivity. You can have whatever opinion you want but it doesn't mean you need to find bad reasons :) >>And since Andi promised to take a shot at making case preservation happen, >>it seems like we are on our way to better interoperability without too much >>BC hassles. > >If get_class() or like returns names with case preserved, >it breaks BC. I expect additional parameter for all of >these functions if it really implemented. Stig answered this one. >I hope not, since it's a additional memory and performance loss... There is no chance in hell you'd notice the additional memory :) And the performance difference would be negligible because what can be done at compile-time is already done in ZE2. Andi -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
