Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111403
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
In-Reply-To: <CAEsg9X0L525jE7hxwPXBJBZwuVPUyvtZuVLBhXi4xFdTL-=sDA@mail.gmail.com>
Date: Sun, 9 Aug 2020 14:36:30 -0500
Cc: tyson andre <tysonandre775@hotmail.com>,
 Manuel Canga <php@manuelcanga.dev>,
 Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <DA4FB2A3-5BEC-4322-9532-B181810B6393@joshbruce.dev>
References: <173d2736435.eeebc066559719.6668730031195302987@manuelcanga.dev>
 <DM6PR07MB66189348DC25742658121507F9470@DM6PR07MB6618.namprd07.prod.outlook.com>
 <CAEsg9X0L525jE7hxwPXBJBZwuVPUyvtZuVLBhXi4xFdTL-=sDA@mail.gmail.com>
To: David Rodrigues <david.proweb@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Import of variables
From: josh@joshbruce.dev (Josh Bruce)

Have not tested - just catching up on emails.

To verify: A property defined with a default value of the global does =
not already do this?

Developer need: I rarely access global variables directly - usually =
going through a lib or framework. When I do I would probably wrap the =
access in a trait or method on a class.

Cheers,
Josh

> On Aug 9, 2020, at 9:58 AM, David Rodrigues <david.proweb@gmail.com> =
wrote:
>=20
> I suggests to make something like Node does: import "file.php" ($a, =
$b) so
> $a and $b must be extracted from file.php context. All other variables
> should be ignored.
>=20
> Or, to avoid create more complexity and possible new keywords to =
import
> syntax, maybe create a new function:
>=20
> importx(string $file, ?array $extract =3D null) and requirex(...) =
(importx
> and requirex is only pseudo)
>=20
> Em dom, 9 de ago de 2020 11:42, tyson andre =
<tysonandre775@hotmail.com>
> escreveu:
>=20
>> Hi Internals,
>>=20
>>> This functionality would allow to create a new  'use vars' keyword =
in
>> order to can use( or cannot use )  global variables in local scope( =
of
>> current file ).
>>=20
>> 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().
>>=20
>> It may be possible to use a declare syntax, e.g.
>> declare(used_variables=3D'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.
>>=20
>> I can see this as having some use cases, such as in configuration =
files or
>> files used for bootstrapping.
>> For example,
>>=20
>> ```
>> <?php
>> declare(used_variables=3Dnull);
>>=20
>> $api_base =3D IS_PRODUCTION ? 'https://example.com/api/' : '
>> http://localhost/api';
>> do_stuff();
>>=20
>> return [
>>    // long config array
>>    'url_new' =3D> "$api_base/new",
>>    'url_all' =3D> "$api_base/all",
>> ];
>> ```
>>=20
>> 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.
>>=20
>> 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).
>>=20
>> 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 =3D []) { =
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.
>>=20
>> Regards,
>> - Tyson
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: https://www.php.net/unsub.php
>>=20
>>=20