> First, in the example referenced above, arguably, making all constants case > insensitive would in fact be the better solution - as you likely don't want > both sOmE_CoNsT and SOME_CONST, or more reaslitically - Some_Const and > SOME_CONST to both exist in your app - a situation case sensitive constants > would happily let you do. That said, I think the scenario of having two > define()'s, both define the same constant with different casing is such an > edge case we really shouldn't put too much emphasis on it.
This argument holds no water in my eyes. 1) Can you tell the difference between YEAR and ΥEAR? I can't. That's a Greek Capital Letter Upsilon, not a capital ASCII Y, in the latter. This situation is worse and irreconcilable. People do this sort of thing from time to time as obfuscation or for clever debugging puzzles. It's not really an issue in practice because it's confusing and so people avoid it. 2) sOmE_CoNsT would be absolutely terrible to type over and over. Nobody will want to subject themselves to it. It might be done from time to time just like the unicode abuse. > Which brings me to the second thing - deprecating features - even if they > aren't the best features in the world - should only be considered if there's > very substantial gain to be had. Breaking compatibility has substantial cost > on our users, and consequently - on the PHP project. While sometimes > breaking compatibility is warranted - for security, reliability or > performance - it is, in general, something we ought to do our best to avoid > if there isn't a strong case for it. With all I've said I still agree here. Deprecating case-insensitive constants *by itself* is not a substantial gain. This is why I opened with my very first reply in this thread on a note of combining it with other features that *would* be substantial. However, other people have really wanted us to focus the discussion on deprecating case insensitive constants only, and if that's what we do I'll be voting "no". However it is something I really would like to see in connection with other features or changes. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
