Hi! > The broader context of this proposal is to provide a simple and usable > mechanism that will allow developers to opt-in to stricter language > semantics on a per-library (or more specifically, per-namespace) basis, > thus alleviating backwards compatibility and library interoperability > concerns for such changes.
I don't think it's a good idea. Not only we'd have two language semantics in one language - which is by itself very far from ideal - but you'd have absolutely no way of knowing which semantics is active for which file by just reading that file. You will have to consider all code that could potentially run up to this point, and all code paths that could have been taken, and could disable or enable strict context. It could also mean that the same code could actually run with both models, depending on the caller - which goes contrary to the whole point of strict declaration. It's way worse than ini setting - at least ini setting is supposed to be one for every install of the code and can't change in runtime depending on code paths. Moreover, this precludes any optimization decision from being made by opcode cache and such - if the same file code can be run in both strict and non-strict context, depending on what was executed before in the same request, it is impossible to make any optimization decision on per-file basis. Moreover, this RFC clearly build an infrastructure for making more semantic forks, eventually leading to the situation where reader of the code has absolutely no idea, looking at the source of certain function, what is actually the semantics of the language and the rules it will be executed under. And neither, even worse, does the author of the code. If that were localized by file, it'd be bad but one could grudgingly tolerate it - you could scroll to the beginning of file and say "oh, sigh, now we're in PHP with strict types, but lax objects, but strict integers, but lax floats, but strict comparisons, but lax conditionals, but strict argument counts! Now I understand what's going on if I only keep in mind those 20 bits that are different in every file!". But after delocalizing it, all hope is lost - you never know what the code in the file actually means - because somebody could write code in completely different file, maybe even JSON composer configuration or some other config file you didn't even think to be able to change your language semantics - and suddenly all the code works differently. Or, for more fun, breaks differently. And you as code author have zero control over it because of the wonders of shared mutable state which now encompasses not only data but the very core of the language. Imagine how fun it is if somebody's action in different code module wouldn't just mess up some data - it would actually break your code by changing language semantics for your code! I don't think it is a good way to write a maintainable software. -- Stas Malyshev [email protected] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
