Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109031
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
In-Reply-To: <DM5PR07MB3067D2DEAD4B3C85FBDFD559F9F80@DM5PR07MB3067.namprd07.prod.outlook.com>
Date: Sun, 15 Mar 2020 18:20:11 +0100
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <38BEBA80-AB6E-484C-A0C4-EF440C27DBD9@cschneid.com>
References: <DM5PR07MB3067D2DEAD4B3C85FBDFD559F9F80@DM5PR07MB3067.namprd07.prod.outlook.com>
To: tyson andre <tysonandre775@hotmail.com>
Subject: Re: [PHP-DEV] RFC idea: Block scoped variables with "let $x = expr"
From: cschneid@cschneid.com (Christian Schneider)

Am 15.03.2020 um 17:47 schrieb tyson andre <tysonandre775@hotmail.com>:
> {
>   let $myObject =3D new MyClass(), $flag =3D true;
>   $myObject->process($flag);
> }
> // Accessing or setting $myObject or $flag outside a different let is =
an E_COMPILE_ERROR
> // because it was declared anywhere else in the function body
> // as a let statement
> $myObject->doSomething();


What you are suggesting is that a let statement would switch PHP to an =
altogether different mode where function-scoped and explicit global =
variables were suddenly disallowed and an error within that function (or =
only after the let?). What about variables not declared with let, would =
they still function normally?
That sounds like a bad idea to me as I'd have to look at the whole =
function to see if there is a let somewhere to determine the =
function's/variable's mode.

I think that 'let' would only be feasible in a similar fashion to =
JavaScript: The lexically scoped variable disappears as if the whole =
block was not there.
How complicated something like that would be to implement I cannot judge =
and I haven't spent a lot of time thinking about other problems of this =
proposal.

- Chris