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

> We might eventually benefit from versioned "libraries" of functions that can be >imported in one command > which would solve many-a-future-problem by itself. I'd be in favor of a module system, I just can't think of a good way to migrate to that with existing limitations. I'd imagine there would be various obstacles/objections to getting an RFC for that approach accepted. Of course, whatever you're thinking of for "libraries" might be completely different than what I think you mean. Proposals for that could start a different thread. For example, if one wanted a module system like NodeJS with "import functions, consts from 'some_native_module_or_php_file'"/"export function ..." 1. Languages such as NodeJS, Python, etc. still have a core set of functions that get loaded even if there are no imports. Those functions can get added to dynamically (see note on polyfills. https://stackoverflow.com/questions/27930038/how-to-define-global-function-in-python is hopefully rare) That would be an argument in favor of preferring deprecating checking in the current namespace, not deprecating the global namespace. (for uses that aren't fully qualified) 2. It's possible for almost any php module's functionality such as "mbstring" to be provided by a native module, or from a pure php polyfill such as symfony/mbstring-polyfill. https://www.php.net/mbstring Or even just a few functions from an extension. I don't know how the equivalent of "import [functions, consts] from 'mbstring'" would work in a portable way, e.g. with a future version of the composer autoloader. 3. This would add more ambiguity if imported names can get overridden (e.g. by MyNs\strlen), making opcache less beneficial to performance. It would also make it harder to comprehend code if exported functions from modules can have aliased names. A more limited version of "libraries" might be possible (pure php only with other limitations) but it doesn't seem as useful.