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.