Re: [RFC] Import of variables

From: Date: Sun, 09 Aug 2020 21:57:26 +0000
Subject: Re: [RFC] Import of variables
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-111407@lists.php.net to get a copy of this message
Hi, Tyson, Thanks. ---- En dom, 09 ago 2020 16:41:44 +0200 tyson andre <tysonandre775@hotmail..com> escribió ---- > Hi Internals, > > To be clear: The variables in the top-level scope depend on what has require()d/include()d a > file. > The top-level scope starts off as being global, but if a file is required from within a > function/method/closure (e.g. the autoloader closure), then the top-level scope in the > require()'d file uses variables (e.g. $this) from whatever context called require(). My idea was using 'use vars' not only with global vars but also with vars in context. > It may be possible to use a declare syntax, e.g. declare(used_variables='all') for > 'all', null, > ['var1', 'var2'], etc. > - Otherwise, you face the issue of where use vars should be > allowed, what happens if there's a statement before use vars, > etc. Good point, I don't think about that. > I can see this as having some use cases, such as in configuration files or files used for > bootstrapping. > For example, > > ``` > <?php > declare(used_variables=null); > > $api_base = IS_PRODUCTION ? > 'https://example.com/api/' : > 'http://localhost/api'; > do_stuff(); > > return [ > // long config array > 'url_new' => "$api_base/new", > 'url_all' => "$api_base/all", > ]; > ``` > > This feature (ignoring the question of syntax) would ensure that people reading the file knew > that $api_base was not modified by other files > and that other files did not read local variables created within a configuration/bootstrapping > file in unexpected ways, > which is a fairly common issue in some web apps I've worked on. > Opcache would also do a better job at optimizing code if it knew which variables in a > top-level scope couldn't be modified. > > That being said, there's been opposition to extensions to the language that add > functionality that can be implemented in other ways, as in Rowan's comment, > but peoples opinions depend on the specifics of the proposal > (e.g. match was added and was more performant than chained > conditionals or switch). > > As Rowan said, there are ways to reimplement this: > - Wrapping the config file or bootstrapping file in a closure, global function, or class > method > - function safe_require_once(string $path, $vars = []) { extract($vars); > require($path); } from the caller, to limit what variables are passed in. > IDEs/tooling would be worse at telling you if a file name had a typo, though. I think in views system( of some frameworks ) or CMS like WordPress. In WordPress, for example, I can do something like this: ## index.php ``` foreach($posts as $post ) { $post = 'foo'; } ``` index.php is loaded from CMS. $post is a global variable used in WordPress core. So that, I am crashing WordPress. However, with: ``` use vars none; foreach($posts as $post ) { $post = 'foo'; } ``` I don't crash my WordPress or any external plugin which can use global vars.. My file now is a container( black box ) where my code is isolated. Regards

« previous php.internals (#111407) next »