Re: [RFC] Namespace-scoped declares, again

From: 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:
     https://wiki.php.net/rfc/namespace_scoped_declares
The 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.
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 of 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.

« previous php.internals (#101348) next »