如何通过引用刀片模板中的@include传递变量?

在Laravel 4.2设置中，我在模板中有一个变量，希望在多个包含项中共享:

In a Laravel 4.2 setup, I have a variable in a template that I wish to share across multiple includes:

master.blade

master.blade

<?php $tabindex = 0; ?>{{--This is the variable--}}
@include('header'){{-- <-in header.blade, I often use ++$tabindex --}}
{{--$tabindex is still 0--}}
@include('content'){{-- <-in content.blade, I often use ++$tabindex --}}
{{--$tabindex is still 0--}}
@include('footer'){{-- <-in footer.blade, I often use ++$tabindex --}}
{{--$tabindex is still 0--}}

$tabindex如果用作tabindex html属性，显然是一个简单的示例，我可以使用安全值和足够大的缓冲区值来解决，但这很难解决，也不是解决当前实际问题的方法.在常规php包含中，据我了解，包含文件中的变量分配会影响包含文件中的变量-这是理想的效果.

$tabindex 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 regular php includes, it's my understanding that variable assignment in included files would affect the variables in the including file - this is the desired effect.

我尝试了View::share()，但是出现了相同的症状.将值作为数组传递给@include显然是按值传递，并且产生相同的效果.

I tried View::share(), but it presented the same symptoms. Passing the value to the @include as an array is clearly passing by value and produced the same effect as well.

几乎似乎首先要对包含范围的值进行完整评估，然后再对所包含的范围进行评估.如果是这种情况，那么如果包含范围或进一步包含的范围(甚至通过某些持久性内存进行存储)中有任何用法，那么我要尝试执行的操作将变得不那么可行，因为执行顺序会有所不同而不是代码中的顺序.

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.

是否存在一些未记录的刀片魔术，以防止刀片@include切断其自身以更改其includer变量的值，或者我必须使用纯PHP include或其他丑陋的替代方法(Session变量应该在调用包含范围内保持它们的值不变，但这只是一种讨厌而脆弱的方法)?

Is there some undocumented blade sorcery to prevent a blade @include from cutting itself off from changing the values of its includer's variables or must I fall back on straight php include or some other ugly alternative (Session variables should persist their values across calling include scopes, but that's just a nasty and flimsy approach)?