On Tue, Jan 14, 2020 at 7:27 PM tyson andre <tysonandre...@hotmail.com> wrote:
> > This RFC proposes to support an opt-in "use global functions/consts;" > statement > > to disable PHP's check for the function/const in the current namespace > before falling back to the global namespace. > > > > https://wiki.php.net/rfc/use_global_elements > > > > > > Earlier discussion can be found in the 'Opt-in "use function *;" for > skipping check for > > function/const in alternate namespace' email thread, which can be seen at > https://externals.io/message/107877 > >Let me know if you have any comments on the RFC > > I plan to update the wiki and start the voting phase tomorrow with the > voting structure mentioned in https://wiki.php.net/rfc/use_global_elements > Alternatives/Arguments > <https://wiki.php.net/rfc/use_global_elementsAlternatives/Arguments> > mentioned in this thread have had summaries added in the discussion section. > Hi Tyson, 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. 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. 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.) 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. 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. Regards, Nikita
