> On Mar 15, 2020, at 2:53 PM, tyson andre <[email protected]> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
