On Sun, 28 Jul 2019 at 04:17, Stanislav Malyshev <smalys...@gmail.com> wrote: > > We've decided not to do INI options to change language behavior,... > because they are - especially when applying to more than local > file - essentially low-grade INI options
I don't agree. What's being proposed are not low-grade INI options. The problems with ini settings is that: * Different libraries could require different settings. * There was no way to manage the settings individually per library. Those problems do not apply to the proposed RFC. As we've seen with the declare for strict types, libraries that want to have strict mode, and libraries that want to have more type juggling, are perfectly fine to live alongside each other, and can be used just fine. > I think it's a wrong way to make semantics of the language to be > different in different libraries. I can't agree. I look at the success of how strict types was brought in, in a way that allowed for zero breaking changes for existing code, and think it was a massively successful way of improving the language without causing problems. I can't understand why someone would make the argument that evolving the language like this is a bad thing. > This looks like potential to create an environment that is > very hard to navigate and keep straight which of the options > is in play for each peace of code. You're saying very negative things about a feature you would not have to use. There have been multiple problems/features over the years that would have been more solvable is we had this RFC implemented. It's fine that you're not convinced that this is a great idea, but please can you stop making the argument that because you don't want to use a feature, no-one should be allowed to use it? cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
