-
Notifications
You must be signed in to change notification settings - Fork 27
external
之所以需要声明external出于两个原因。
首先,不进行声明,jedi的PHP编译器无法区分是 $data->isset(x) 还是 isset(x) ,尽管我们从来不写前者,但是我感觉没有足够的理由去禁止这种可能——尤其是考虑有交互或表单的页面,模型上直接给方法如model.action()也许正是合理的设计。另外如果不加声明,编译器也无法区分 $data->Category->load 还是 Category::load。
其次,我们很早就讨论过,从代码质量、可测试性等角度出发,View所能访问的所有东西应该是受控的,也就是只有$data上的东西。从这点出发,要求明确声明外部函数其实是用代码将该view的相关因素固定下来。之前一次Review,排总提到过这个会造成对外部PHP的代码依赖,有可能在变更外部代码时产生bug。不过这个事情只要你用了外部PHP函数,是总会发生的。而且这样是工具友好的。
而要根本上解决这个问题,就是像翔子说的要丰富jedi语言本身的内建特性。这其实很早跟赵赵也讨论过——镐京的架构目标中其实有一条是希望Controller做薄,而要做薄Controller,就是在model和view两个方面要增强,减小controller的负担。model方面的增强依靠graph API来达到,而view方面的增强需要靠模板语言本身表达式必须加强。但这件事情有许多细节需要推敲,由于时间不够,所以被我暂时搁置了。
总之,明确的external声明只是把对PHP过多的外部依赖这个问题显式的列在那里,这至少把问题列到了明处。长期来说,只要jedi的内置特性和表达式进行增强,需要external的东西会越来越少,基本上只有极少的个案会用到。
BTW,当前的external存在两个小问题是有待改进的: 一个是按照设计目标external应该在整个模板或者子模板的最前面,但是由于子模板继承实现做的不是最完善,导致现在在被extended出来的模板中external必须写在模板钩子里。 另一个是最好像GO语言的import一样,对于声明了但是实际没有用到的external要报错或者warning。