Re: RFC idea: Block scoped variables with "let $x = expr"

> On Mar 15, 2020, at 2:53 PM, tyson andre <tysonandre775@hotmail.com> wrote: > > Hi Mike, > >> What I would rather see are new features in PHP that encourage developer >> to break functionality into shorter and simpler functions and methods, and to minimize >> nesting. > > I would also like to see shorter functions in general, but: > > - Other developers may prefer long functions/scripts despite my preferences, > but their code would still benefit from readability by having block-scoped variables enforced > by the compiler What I am about to say is ironic since I too often feel people are trying to enforce their view of coding on the world, but I do not think we want to give people tools to make it easier to work with long functions/scripts. And while I do understand that other people can disagree, please understand I am just stating my opinion here. > - Some problem domains are complex (e.g. business logic) and require a lot of variables, > leading to long functions/scripts, and trying to split them up may be error-prone > or cause awkward divisions of functionality. I would be very interested in seeing business logic coded into a long function that literally cannot be made better by refactoring into multiple smaller functions. If you have some, please do post to a Gist and share it to see if it in fact it cannot be refactored and made "better." > - Even in short functions of a few dozen lines, it may be useful to know if reused variables > such as > $i are definitely scoped to a loop, when reviewing code. > >> There is also an issue with block scoping that is reasonably well-known >> among the GoLang community called variable shadowing >> and that is a developer seeing a variable in block scoping >> and thinking they are accessing or assigning the function-scoped variable. > > Variable shadowing is also an issue in JavaScript. > While JavaScript and GoLang don't allow introspection of the variable scope > (as far as I know, not sure about reflection), > PHP does allow dynamic access by name ($$var, > get_defined_variables()['var'] in a require()d file, > XDebug), > and any proposal for block scoping in PHP will need to account for that somehow. > > - Aside: Personally, I set up linting for golang projects to forbid shadowing. > > My best plan for dealing with variable shadowing in PHP was to forbid it entirely, > which I mentioned examples of in the proposal. > >> { >> let $outer = 1; >> { >> let $outer = 2; // E_COMPILE_ERROR to declare in a different (shadowed) scope, can >> only reassign >> $outer = 3; // this is allowed >> } >> } > >> P.S. If you really need block scope within a long function or method you can already create >> a closure and call it in the same expression: > > I'm aware of this and have used it (e.g. to avoid modifying the global scope in large > projects), > but avoid it in functions due to the awkward syntax and the performance overhead of function > calls. Given the nature of long functions, I think the awkward syntax here provides a nice disincentive to writing overly long functions. But as I said, the closure does exist in case someone absolutely needs to control the scope of a block within an existing long function, such as the 1400 line function I've been refactoring for months now... > I'd generally just use a different variable name. > > - Tyson