Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102224
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1528697673100.21360@ku.edu>
References: <CAP=4hCK5BYcUhDGtAHggkAysMZiuraOfBt3TWge0g46GcT0X8g@mail.gmail.com>
 <BN6PR02MB323425E29746D9C173CF67A0BF7A0@BN6PR02MB3234.namprd02.prod.outlook.com>
 <CAP=4hCJxVhF3Y_qmdzGoWs6EsoxhhX-qWtCf26q=Er_C3ZTq0A@mail.gmail.com>
 <1528656103200.14318@ku.edu> <fbee7639-3b69-2d91-71fd-f8de33949f27@gmail.com> <1528697673100.21360@ku.edu>
Date: Mon, 11 Jun 2018 10:12:27 +0100
Message-ID: <CALKiJKp3y2GS7K5HzxtUN4KJgUKJVwNsUWSqGc920KDfzZEk+w@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000112c38056e5a26ec"
Subject: Re: [PHP-DEV] [VOTE] Make compact function reports undefined passed variables
From: rowan.collins@gmail.com (Rowan Collins)

--000000000000112c38056e5a26ec
Content-Type: text/plain; charset="UTF-8"

On 11 June 2018 at 07:14, Hoffman, Zachary Robert <zrhoffman@ku.edu> wrote:

>
> However, even if those 4 values end up being stored in a structure, I
> don't want to manipulate that structure within that class method itself, I
> want to perform computations with local variables. If I have to separately
> store those variables to the structure at the end of the method, that is
> fine.
>

If the variables have to share a name with the fields in the structure,
they're not really local variables - you can't rename them, add more
intermediate steps, etc, without breaking their magic affinity with the
named fields.



> I end up using `compact()` in the same way when rendering Blade views from
> Laravel controllers, which is easier to demonstrate, so I made a small
> Laravel project to demonstrate `compact()` being useful. It is viewable at
> https://gitlab.com/zrhoffman/compact-example . The project only consists
> of 2 short files (which are copied into a Laravel base install), which I
> will paste here anyway.
>

I can see why this code is tempting, but it looks very "closely coupled" to
me: *why* are the local variables in the controller named the same thing as
in the view? What if the word "power" is ambiguous in the context of the
controller, and so you want to rename that variable $exponent? Because
you've assumed you can use compact(), you can't do that without tracing the
variable through the whole application - these are now effectively global
variables, rather than local ones.


We could still avoid it on our end by rewriting the return statement of the
> Laravel route to this:
>
> return view('index', [
>     'power' => $power,
>     'sum' => $sum,
>     'xor' => $xor,
>     'base' => $base,
> ]);
>
> Since I am necessarily expecting those variable names on the other side
> anyway, this seems like extra effort worth avoiding.
>

The fact that the keys and values look so similar here is a coincidence of
the current implementation, and making that explicit is not wasted effort.
If you refactor the code and rename the local variable $power to $exponent,
even the most naive refactoring tool will give you working code:

return view('index', [
    'power' => $exponent,
    'sum' => $sum,
    'xor' => $xor,
    'base' => $base,
]);

This is a huge advantage in maintainability of the code - it's easier to
understand, harder to break, and more able to evolve.




> The other reason I mentioned Laravel is that storing variables by key in
> an array and extracting them later is intrinsic to Laravel's process for
> rendering views, and writing "fundamentally dynamic code" is pretty much
> inescapable in this case.
>

Yes, I've seen Blade (and templating generally) as a justification for
dynamic variable names before, and I can see the appeal of reusing the PHP
engine as the templating engine, with a different set of variables in
scope. It could, however, be considered syntax sugar rather than truly
dynamic variable names - a template compiler could convert "$foo" into
"$params['foo']", just as it converts other Blade-specific language
features.


Regards,
-- 
Rowan Collins
[IMSoP]

--000000000000112c38056e5a26ec--