> I like the idea of using a meaningful value here, but think that this
> should be using a string, i.e. declare(function_and_const_lookup='global')
> rather than declare(function_and_const_lookup=global).
Also, I could make that a voting option, and it could be changed before 8.0
alphas if new concerns come up after a vote.
> This looks a bit peculiar... We could also say that declaring a symbol also
> automatically brings it into scope.
> I'm not really sure which is better.
Neither am I. There were edge cases with doing that that may cause more
confusion
namespace NS;
function f() { /* calls g() - which g() */ }
function g() { /* calls f() */ }
if (!function_exists('NS\h')) {
function h() {}
} else {
// what will h() refer to
}
// what will h() refer to
> As a general note on the overall proposal: I think this is a very pragmatic
> proposal. It addresses a real issue, and it addresses it in the most
> straightforward way. You can just drop the declare in your code, and it will
> keep working exactly as it did
> before, just faster. Assuming you weren't doing anything stupid, of course.
>
> The big downside is that this makes class and function symbol resolution
> complete opposites. Classes only look in the current namespace. Functions
> only look in the global namespace. This reflects the way they are most
> commonly used, but is not a great
place to end up from a language design perspective.
>
There are two alternatives that keep class and function symbol resolution the
same: One is to always only look in the namespace. This has been suggested a
few times in the past, including in this thread, and the RFC
https://wiki.php.net/rfc/fallback-to-root-scope-deprecation. I think this is a
fairly unpopular option, because using fully qualified names for functions
tends to be quite ugly (more
so than for classes, due to the positions they're used in), or requires a
large number of imports, as even a small piece of code can easily use a dozen
different string/array functions.
Agreed
> One option that I haven't seem much discussion on is the opposite: Always
> only look in the global namespace. Any unimported unqualified usages will be
> treated as fully qualified names.
> This would match the proposed semantics for functions/consts and change
the resolution rules for classes.
> I think this would have relatively little impact on how code is written, as
> classes already tend to make extensive use of cross-namespace references and
> the import is usually IDE managed.
Also, about the note on classes.
It's fairly common for NS\SubNS\ClassName to mention other classes from
NS\SubNS\OtherClassName right now,
(more commonly than use Exception, use Throwable, etc in some cases),
and changing that default would require changing a lot of third party code.
A separate option such as `declare(lookup_classes=global)` would allow
migrating to that,
but would confuse developers switching between codebases using different
settings of lookup_classes,
and introduce similar confusion about the rare case of multiple classes in one
file.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
