I'll be postponing the vote to update the RFC and proof of concept/tests associated with it to use declare()
Also, "declare(lookup_functions_in_current_namespace = false, lookup_consts_in_global_namespace = false)" in the file's declare() blocks was my first idea. Any ideas - declare(disable_ambiguous_element_lookups=1), declare(disable_ambiguous_lookups_in_current_namespace=1), etc? x=1 seems to be more common, and reflects the fact that this is not the default. > I don't think it's a good idea to resolve the question of "use global > functions" vs "declare" as a subsidiary vote. > At least in my mind, those two options are significantly different, and this > choice would affect both my overall opinion of the proposal > and also the answer I would give on some of the other voted question. Agreed, I had some of those concerns after suggesting setting it up that way. It doesn't capture "accept if one option, but not if the other option". Ideally, I could have a vote for the syntax to use for the RFC, then amend the RFC with the syntax, but that isn't practical. > The RFC already outlines a number of reasons why it is preferable to > implement this as a declare directive, > so please excuse my reiterating some points here :) > First and foremost, if we ever implement https://wiki.php.net/rfc/namespace_scoped_declares or some similar way of specifying declares on the package level, > and I think it's pretty likely that we're going to do this in one form or > another, then we're very much going to regret not making this a declare. > Disabling the namespace fallback, just like the use of strict types, is > something you will usually want to do for an entire library/project, not just > for individual files. > Going for something like "use global functions" preemptively precludes this > for no good reason. That's a good point. I think that's the first time I've seen that RFC. https://wiki.php.net/rfc/namespace_scoped_declares#nesting_behavior / https://wiki.php.net/rfc/namespace_scoped_declares#implementation_considerations answers my questions about how that would work with readability/opcache. It'd definitely be convenient to have less boilerplate. > Second, I think phrasing the semantics in terms of a change to name > resolution behavior (which the declare does) > is clearer than phrasing it as "import all functions/consts in the global > namespace". > That's not really what this this feature is doing on a technical level, and this phrasing is what results in questions regarding the behavior for various conditions regarding symbol overlaps etc. > For example, with the declare, I don't think that it should be an error to > make a function declaration inside a namespace > -- that's still entirely well defined, and I think a legitimate use-case > (a project that is disabling namespace fallback everywhere, will likely want > to do that for files declaring functions as well, as a matter of consistency.) My concern was about this being well-defined but being likely to be accidentally misused, e.g. with namespace-scoped declares. Same for NS\my_printf calling \my_sprintf instead of NS\my_sprintf within the same file. Explicitly changing to namespace\my_sprintf() or uses would be one way to migrate code like that. namespace Example; use global functions; // or declare() // interpreting this literally, without `use Example\fact;` instead of namespace\fact, this is calling \fact(), which is surprising // (the old equivalent `use function fact;` would throw because of the name reuse) function fact($n) { return $n > 1 ? $n * fact($n - 1) : 1; } > Third, I'm not sure it makes sense to separate this functionality for > functions and for constants. > I can't really imagine a situation where you would want to, say, use > namespaced constants but global functions. > I can see why you went with this split when using the "use" syntax (as we > already have "use function" and "use const" both), > but with a declare approach, I would suggest to combine both. Functions and > constants live in different symbol spaces, > but their name resolution behavior is the same. If you're declaring a function or a constant in a namespace, the way I implemented it would throw an Error at compile time to avoid confusion. If it didn't throw an Error, then I'd agree that it'd virtually always be used together, except possibly when migrating to being stricter gradually. > Finally, if you do want to go with the "use" syntax, "functions" and "consts" > should not be made reserved keywords. > There is no technical need for these to be true keywords, so we can avoid an > unnecessary BC break here. Agreed for future work on "use" -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
