Re: Re: [RFC] "use global functions/consts" statement

> 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.