On Tue, Dec 12, 2017 at 8:46 AM, Stanislav Malyshev <smalys...@gmail.com>
wrote:

> Hi!
>
> > The idea is to allow specifying declare directives for a whole library or
> > project using:
> >
> >     namespace_declare('Vendor\Lib', ['strict_types' => 1]);
>
> I am not sure I like this. Namespace is a prefix to a class name.
> Anybody can declare a class with any name, and the side-effect that they
> would inherit some context, which is completely invisible and would
> magically exist somewhere globally, does not seem like a good idea to
> me. Moreover, what if something - like older version of the same library
> or test or something like that - would have different idea about what
> that global state should be? How nice would it be if a piece of
> unrelated code could completely change how my code is interpreted? How
> nice would it be if whether it works or not would depend on in which
> order classes were loaded in this particular request?
>

The way PHP works, it's not possible to have two versions of a library
loaded at the same time. There are projects like
https://github.com/humbug/php-scoper to allow loading a library multiple
times, which work by prefixing all namespaces. Of course, in this case
namespace_declares() would also be applied to different namespaces and
there will be no interference.

There is no dependence on loading order. The implementation is careful to
ensure that the used declare state is consistent. It's not possible to call
namespace_declare() twice on the same namespace. It's not possible to first
load some files from a namespace, do the namespace_declare() call and then
load some more files. If a namespace_declare() call succeeds without
throwing an error, then that is the ground truth, without any dependence on
order or other calls.


> Hidden global context has the same smell as php.ini settings, and for
> the same reason - but this, as far as I can see, will also be hidden and
> depending on file loading order, class loading order, etc. which in big
> applications can lead to a lot of fun debugging why some code randomly
> produces fatal errors... Debugging PHP is fun enough without quantum
> entanglement-like effects :)
>

As said above, the implementation makes sure that all quantum state is
collapsed ;) The only possible mistake that can occur is that the
namespace_declare() call doesn't happen at all, but anything depending on
loading order or conflicting calls is not possible.

The big issue with ini settings is (mostly) not the "hidden" part, it's the
"global" part. Ini settings that change language behavior are tabu because
they apply to everything, so no library can assume any particular ini
configuration. Namespace-scoped declares explicitly avoid this. A library
can namespace_declare() it's configuration and be sure that this is the
configuration it's going to get, at the same time not interfering with any
other library or code that uses a different configuration.

> 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.
>
> Where "soon" means "for all practical purposes, forever, unless we stop
> calling that new thing PHP", IMO.
>
> > Namespace-scoped declares are perfectly suited to resolve this problem.
> We
>
> I don't think so. First of all, I don't think, of course, that this
> problem needs to be solved by adding more complexity to save a purely
> cosmetic feature. But second of all, I don't think global hidden context
> that could change at a distance how the code is interpreted is a good
> idea regardless of whether it solves the issues with send-by-ref.
>

I haven't thought too carefully about whether having an option for the
explicit-send-by-ref feature *specifically* would be beneficial, but I
think it's very important to at least have the option on the table. Too
many issues in PHP cannot be solved for reasons of backwards-compatibility.
We need to have *some* way to evolve the language without BC breaks, and I
think namespace-declares are an elegant way to do this.

Regards,
Nikita

Reply via email to