Pierre, > De : Pierre Joye [mailto:pierre....@gmail.com] > > > I case we would designed a new language I would rise two hands. > > Changing, syntax in an existent widely used language is an additional pain > > for users. > > Technically it shouldn't be very difficult to remove support for > > case-insensitivity, and it'll even improve speed and memory consumption, > > but I don't think it costs the compatibility break. > > I fully agree and why I will vote no on that. Even if I know many > projects that won't even notice such changes. But I also have no idea > how many 1000s projects out there won't be as happy.
Don't worry, I won't bother anyone with a vote at this stage. I have started an RFC to keep a track and explore the topic but it is a complex subject. It is even *many* more or less independent complex subjects. Anyway, some may be easier than others, for different reasons (just personal opinions, to be confirmed in each case) : - Namespaces are relatively new. We might expect code using them to be 'cleaner', - We can probably quite easily deprecate support (internal and userland) for case-insensitive functions by just making null, false, and true case-sensitive and adding new NULL, FALSE, TRUE, Null, False, and True. Probably no need for fAlSe or tRUE :) - __halt_compiler() does not represent much but has the benefit of being an easy case :) - magic methods are already more risky but may be imagined with some case-sensitive aliases added. The rest is more complex, and would necessitate extensive impact studies. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
