RE: [PHP-DEV] Deprecate and remove case-insensitive constants?

> -----Original Message----- > From: Christoph M. Becker [mailto:cmbecker69@gmx.de] > Sent: Tuesday, September 12, 2017 3:03 PM > To: internals@lists.php.net > Subject: [PHP-DEV] Deprecate and remove case-insensitive constants? > > Hi everybody! > > Usually constant identifiers are treated case-sensitive in PHP. This is always > the case for constants defined via a const declaration. > However, define() allows to pass TRUE as third argument to define a case- > insensitive constant. This feature appears to potentially result in confusion, > and also causes bugs as shown in > <https://bugs.php.net/74450>. See an > example created by Nikita to see some probably unexpected behavior: > <https://3v4l.org/L6nCp>. > > Even if these issues could be resolved, I still think allowing both case- > sensitive and case-insensitive constant identifiers does more harm than > good, so either case-sensitive or case-insensitive constant identifiers should > be removed from the language. Since case-sensitive constant identifiers are > already the default, and HHVM doesn't even support case-insensitive > identifiers at all, I would suggest to remove case-insensitive constant > identifiers. Even though I don't think it's the end of the world if we remove case insensitive constants, I think there are a few things to consider. 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. 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. Does deprecating case insensitive constants clear the bar of 'substantial gains to be had'? Personally, I don't think so. Yes, a marginal edge case that took almost 20 years to surface would become marginally better (and that edge case is arguably better served by deprecating case sensitive constants) - but in my opinion, that hardly clears the bar for the 'substantial gains to be had'. The marginal simplification to the engine is unlikely to bring big news either - it's not as if we've been investing tons of cycles on maintaining that part of the code anyway (FWIW, in response to #74450 I would simply state that defining overlapping case sensitive and case insensitive constants results in undefined behavior - I wouldn't try to solve it, it is as edgy as edge cases get). If I had to guess, in the vast accumulated PHP code base out there - the majority of which is outside our reach to review, constants defined as SOME_CONST and used as Some_Const (or some_const, or vice versa) are most probably out there (e.g. in situations when the author of a library prefers one type of casing and the application author prefers another). Not a major issue, we'll survive this if this deprecation goes through, but we will also survive just fine if it doesn't - and the likely net effect on our userbase would be less negative. My 2c. Zeev