> 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_*}`).
If this is allowing prefixing with backslashes, the "surface area" isn't
guaranteed to be enumerated in one place.
Forbidding backslashes or namespace aliases for functions/constants would have
other objections.
> 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.
The issue would be that I'd expect it to be voted against for similar reasons
to my RFC, but it's easy to implement.
`declare(function_and_const_lookup='global')` aimed to make something that was
inconvenient to work with
with tooling more convenient in some ways with and without tooling.
Right now, it's already possible to fail your build if a file uses unqualified
names, without code changes.
Tools like `phpcs` and `phan --plugin NotFullyQualifiedUsagePlugin` can be run
in continuous integration or as a check on file save,
and have ways to detect the lack of explicit qualifications.
(If a project could set up `php --syntax-check` on all files, they could likely
also set `phpcs` checks up).
Having a file `strict_qualify=1` throw/exit after a deployment or code release
would be undesirable
(emitting a compiler warning when compiling would be safer, but make that
setting a less useful guarantee of strictness)
It's possible to implement from a technical standpoint:
the lines that get changed are the same ones you can see in the PR for my RFC.
(If you mean throw at compile time, not at runtime)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
