> 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to