Re: [RFC] Namespace-scoped declares, again
| From: | Ivan Enderlin | Date: | Wed, 13 Dec 2017 06:36:10 +0000 |
| Subject: | Re: [RFC] Namespace-scoped declares, again | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-101348@lists.php.net to get a copy of this message | ||
On 11.12.17 14:43, Nikita Popov wrote:
Some time ago I introduced the following proposal for namespace-scoped declares:While it seems comfortable for the user, and I understand the point you're trying to solve somehow, it can be a nightmare for the VM, the developer, and the user. I've few remarks and/or questions: * When parsing a file, the way the VM has to interprete/execute the file depends on a _runtime_ configuration defined in _another_ file. It makes things more implicit, and that's not good. * It can also be a nightmare for the developer. The behavior of their library can be changed by another library because there is no restriction about the location or usage ofhttps://wiki.php.net/rfc/namespace_scoped_declaresThe idea is to allow specifying declare directives for a whole library or project using:namespace_declare('Vendor\Lib', ['strict_types' => 1]);I've finally gotten around to implementing this proposal ( https://github.com/php/php-src/pull/2972) and would like to move forward with it. The reason why I'm picking it up again is some feedback I received for the explicit call-time send-by-ref proposal. The main objection seems to be that the feature has limited usefulness if it's optional rather than required, because you still can't be sure that something is a by-value pass, just because no & is present. At the same time, we can't make this required anytime soon due to the large BC impact. Namespace-scoped declares are perfectly suited to resolve this problem. We can introduce a require_explicit_send_by_ref declare directive to make the call-site annotation required, and libraries/projects can easily opt-in to it using namespace_declare(). There would be no BC impact, while at the same time projects could benefit from the additional clarity and performance improvements immediately. Thanks for the proposal.
namespace_declare. If at least namespace_declare would only apply to the _current_ namespace, it might be better.
* If namespace_declare is called twice for the same namespace, an error is raised, OK. It's easy to break someone's code by registering a file in an autoloader to load first, and call namespace_declare for that file. What the error will look like? It's important to prompt the correct culprit to the user. Any strategy to find which one is the culprit?
* As you said in the RFC in the Proliferation of declare directives Section, it's not a good thing for the language to introduce more and more directives. PHP is living a time where it makes good things easier to do, and bad things harder to do. Everything I can imagine with namespace_declare is definitively not good for the language, the VM, and the ecosystem. Introducing a strict mode for the language is definitively a good thing to progressively make PHP stricter, yes, but I don't see a real need or a real motiviation behind namespace_declare, I for one see only dangers.
So I'm sorry to say that —right now— I'm totally oppose to this RFC :-).
Cheers.
-Ivan.