On Mon, Jun 25, 2018 at 8:03 AM, Stanislav Malyshev <smalys...@gmail.com> wrote:
> Hi! > > > https://wiki.php.net/rfc/case_insensitive_constant_deprecation > > > > This was already discussed some time ago on the list, though that > > discussion degenerated into unfortunate directions. I'd very much > > appreciate if we could keep discussions on making PHP fully > case-sensitive > > or fully case-insensitive outside of this thread. (Feel free to open a > new > > one though.) > > > > The main point I'd like to have feedback on is the handling of true, > false > > and null, as I'm not sure what the best approach regarding that is. > > I think the must is to keep true/false/null working in all cases. I > don't think messing with this would be acceptable due to amount of code > it'd break. > > Now, I think breaking constant("null") could be acceptable in PHP 8, if > necessary, as use case for this seems to be very narrow. However, I > wonder if we can't just special-case those three in constant() function > and write "for historical raisins, this is weird" and be done with it. > Not ideal, but practically might be good enough. > > Converting them to keywords should be fine - am I wrong to think the > impact would not be that big with new parser, as we now have less places > where keywords are banned? > > As for the rest, I think we should get rid of case-insensitive constants > (including defined by extensions) and all the weirdness that follows. > Deprecating them would be a good first step. > Regarding making true/false/null reserved keywords, the state is as follows: * true/false/null are already reserved class names, so they cannot be used as class names already (no BC break here). * Method and class constant names are not subject to reserved keyword restrictions (no BC break here). * Global constants (e.g. in namespaces) already check against true/false/null, though there are unintentional loopholes (no BC break here). * Function names can still use true/false/null right now. So basically the practical BC impact of making them reserved keywords would only be a) cannot be used via constant() anymore and b) can't declare global functions with these names. Given that making them reserved keywords is otherwise the cleanest solution, I think we should go with that. Are there any other opinions on this topic or the RFC in general? I'm a bit surprised that there are so little comments after the somewhat explosive discussion last time around. Nikita
