On Wed, Jan 29, 2020 at 5:56 AM Marco Pivetta <ocram...@gmail.com> wrote:

> I voted "No" on this one, sorry.
>
> TL;DR: I'd rather have a mechanism to disable global function fallback, not
> something that makes un-imported symbols immediately global.
>
> The idea to disable PHP's implicit
> "fallback-to-something-that-may-or-may-not-exist" is great, and it could
> simplify some of the engine, as well as remove some caching mechanisms
> (lookup) in some contexts, but I'm pretty happy with disabling all global
> lookup functionality, rather than making them the default.
>
> I don't have a problem with `use function sprintf;` to import things from
> PHP, and actually use it to quickly grep whenever I do something extremely
> dangerous (like `use function umask;`).
> This gives me also a good overview of how much of the global symbols are
> still in my system, and to be replaced with something like
> `thecodingmachine/safe`.
>

Agreed. I want to force explicit qualifications, and raise error on
unqualified names:

<?php
declare(strict_qualify=1);

namespace foo;

use function \{array_diff, var_dump};
use const \bar\{a, b};

$x = array_diff(a, b);
if (count($x)) { // throw an \Error of some kind, as count is unqualified
    var_dump($x);
}

Pros... no bc break; short declare identifier with obvious values; code
valid even if declare is removed; no lookup performance penalty; easy to
remember logic; forces enumeration of the "surface area" the code wants to
cover (which in turn helps developers think about how much work the code's
doing); has analogue in other similar languages (perl, python, node); makes
explicit what functions are being used and where they originate; might goad
an implementation of wildcard use (use function \{imap_*}).

Cons... have to enumerate everything, potentially lots of work to do that
to update old code to use; edge cases I'm not thinking about.

I've not done the work to implement this, though I am happy to if there's
interest. But, it may not be feasible. I'd hope Tyson would kindly say
"STFU not possible"  if, from their recent experience, it couldn't be done.
Apologies if earlier thread discussion ruled this out categorically.

But I like that it adds super-strictness for those who want that, while
keeping the super-flexibility of what we have now. That seems to be the way
we're going with this dual-world of loose- and strict-ness in PHP.

Reply via email to