title: How to pass variables by reference to @include in a blade template?
body: <p>In a Laravel 4.2 setup, I have a variable in a template that I wish to share across multiple includes:</p>
  
  <p>master.blade</p>
  
  <pre><code>&lt;?php $tabindex = 0; ?&gt;{{--This is the variable--}}
  @include('header'){{-- &lt;-in header.blade, I often use ++$tabindex --}}
  {{--$tabindex is still 0--}}
  @include('content'){{-- &lt;-in content.blade, I often use ++$tabindex --}}
  {{--$tabindex is still 0--}}
  @include('footer'){{-- &lt;-in footer.blade, I often use ++$tabindex --}}
  {{--$tabindex is still 0--}}
  </code></pre>
  
  <p><code>$tabindex</code> if used as a tabindex html attribute is clearly a trivial example that I can get around with safety values and a large enough buffer value, but that's hardly elegant or a solution to the actual problem at hand. In <a href="http://php.net/manual/en/function.include.php" rel="nofollow">regular php includes</a>, it's my understanding that variable assignment in included files would affect the variables in the including file - this is the desired effect.</p>
  
  <p>I tried <code>View::share()</code>, but it presented the same symptoms. Passing the value to the <code>@include</code> as an array is clearly passing by value and produced the same effect as well.</p>
  
  <p>It almost seems like the including scope values are evaluated first in their entirety, and then the included scopes. If this is the case, it would make what I'm trying to do much less feasible if there is any usage in the including scope or further included scopes (even storing by way of some persisting memory) because the order of execution would be different than the order in the code.</p>
  
  <p>Is there some undocumented blade sorcery to prevent a blade <code>@include</code> from cutting itself off from changing the values of its includer's variables or must I fall back on straight php <code>include</code> or some other ugly alternative (<code>Session</code> variables should persist their values across calling include scopes, but that's just a nasty and flimsy approach)?</p>