On 11 June 2018 at 07:14, Hoffman, Zachary Robert <zrhoff...@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]
