Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101348
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain hoa-project.net from 217.70.183.198 cause and error)
To: Nikita Popov <nikita.ppv@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAF+90c_Ctjja=8fR-uBWL1wDxZge771yMujMhaR_R2seKXciYw@mail.gmail.com>
Message-ID: <47d2a605-089a-ed08-580e-dd505d1a6381@hoa-project.net>
Date: Wed, 13 Dec 2017 07:36:10 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0)
 Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c_Ctjja=8fR-uBWL1wDxZge771yMujMhaR_R2seKXciYw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Subject: Re: [PHP-DEV] [RFC] Namespace-scoped declares, again
From: ivan.enderlin@hoa-project.net (Ivan Enderlin)

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.