> -----Original Message----- > From: morrison.l...@gmail.com [mailto:morrison.l...@gmail.com] On Behalf > Of Levi Morrison > Sent: Saturday, September 16, 2017 6:25 PM > To: Zeev Suraski <z...@zend.com> > Cc: Christoph M. Becker <cmbecke...@gmx.de>; internals@lists.php.net > Subject: Re: [PHP-DEV] Deprecate and remove case-insensitive constants? > > > 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.
I'm genuinely not sure how it's related to what I said. If someone is a 'clever' developer trying to intentionally obfuscate their code, good luck to them. PHP shouldn't try to stop them. We shouldn't care about these cases - not care a bit, but not at all. > 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. True, but here too, I'm not sure how it's related to what I said. The only relevance I can think of is if you think sOmE_CoNsT is something I came up with and is my idea of coding, and it's not - it's taken from the bug that got this all thread started in the first place (bugs.php.net/bug.php?id=74450). A more realistic case would be SOME_CONST, Some_Const and some_const, used interchangeably within a multi-layered app. I can totally imagine someone consistently using Some_Const everywhere, while the definition was for SOME_CONST. > > 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. Fair enough, but for now I'm focusing on the original proposal. Zeev
