On 04/20/2012 08:48 PM, C.Koy wrote: > On 4/20/2012 8:57 PM, Kris Craig wrote: >> >> Turkish localization notwithstanding (I confess that I know absolutely * >> nothing* about that lol), one possible use-case could be if you're >> including an external library/framework that contains a function with the >> same name but different case. I'm not sure how likely that is, mind you, >> but I can see that as one potential benefit. Either way, I guess my >> point >> is that the arguments for/against this seem to parallel the arguments for >> Windows-style fso case-insensitivity vs. Unix-style fso case-sensitivity. > > Java, C#, Python, Ruby... are all case-sensitive. This is not a feature > to be (mis-)used so that one can have a function named myfunc() and > MyFunc() in the same code base. > Case-insensitive class/function/interface names is a confusion for > everyone with non-PHP development experience. There's not a modern OO > platform that defines an interface named 'IDispatch' and later allows it > to be referenced as 'idispatch' or 'iDispatch'. And PHP is becoming more > OO with every major release. > Overall, full case-sensitivity seems to be a natural step in PHP's > evolution.
I also have the feeling that cleaner code with consistent case would be a benefit. While I admit we can't change that from one day to the other (as we couldn't with other changes) I think we might possibly add a special kind of "deprecation" where the non-matching case would still work but (if you activate those deprecation-warnings) would trigger warnings so you can clean up your code. Various projects that I work on take explicit care of the case when auto-creating classnames etc. - not because they must but because they want to be consistent. And that's the thing I like about it. Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
