Re: Opt-in "use function *;" for skipping check for function/const in alternate namespace

From: Date: Thu, 28 Nov 2019 10:17:39 +0000
Subject: Re: Opt-in "use function *;" for skipping check for function/const in alternate namespace
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-107881@lists.php.net to get a copy of this message
> > What are your thoughts about syntax such as the following, similar to the syntax for Java (only > for use of functions/constants from the root scope) > > <?php > namespace My\NS; > use function *; > use const *; > // can use functions/constants from namespaces that aren't the global namespace to > override '*' > // "use *" is not valid. > printf("PHP Version is: %s\n", PHP_VERSION); > I am in support of this, and my personal code still doesn't use namespaces at all due to things like this, relating to the handling of functions in the language. I personally think that the whole 'autoloading' concept is a bad idea, and ahead of time import and compilation to bytecode, as offered by preloading is a far better idea. On Thu, 28 Nov 2019 at 00:02, tyson andre <tysonandre775@hotmail.com> wrote: > > > What are your thoughts about syntax such as the following, similar to the syntax for Java (only > for use of functions/constants from the root scope) > > <?php > namespace My\NS; > use function *; > use const *; > // can use functions/constants from namespaces that aren't the global namespace to > override '*' > // "use *" is not valid. > printf("PHP Version is: %s\n", PHP_VERSION); > > A similar opt-in directive syntax "use function root;" was mentioned as an > alternative to the "Deprecation of fallback to root scope" RFC > https://marc.info/?l=php-internals&m=151788196501507&w=2 . > (I couldn't find any other mentions after a quick search) > > Benefits of "use function *": > - Visually cleaner and less prone to merge conflicts than "use" for dozens of > functions/constants all from the root scope. (or writing \printf("PHP Version is: %s\n", > \PHP_VERSION), or mixes of the above) > - Due to the absence of function autoloading (not supported in php to performance overhead), > functions outside the global scope are rare in practice. > - This would make it easier to make edits to a project (if the project's code style > involves the unambiguous use of functions/global constants) > - This makes using unambiguous functions/global constants easier. (for a small performance > boost due to the php interpreter not needing to check both namespaces, opcache knowing exactly which > function/constant it is, etc) > - Does not break third-party code > > The other RFC > https://wiki.php.net/rfc/fallback-to-root-scope-deprecation had the > following notable objections, and I'm not sure of the current status of it: > > - Deprecating the behavior of existing code would break (possibly unmaintained) third-party > libraries and require a lot of code changes, discouraging updates > > "use function *;" wouldn't. > - Some mocking libraries will declare functions in namespaces being tested, with the same name > as the global function. > My proposal has similar drawbacks - third party code that started using "use function > *" would break those libraries (but so would manually adding the same namespace uses). > > But there are alternatives to those libraries, such as uopz, runkit7, and SoftMocks > (SoftMocks changes the class autoloader to replace code with instrumented code). > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >

« previous php.internals (#107881) next »