for语法对于自定义集合的支持

[otakustay]

简单来说，现在的etpl并不支持backbone的Collection，也不支持emc的Collection，因为它们封装了数组，并且没有暴露出类数组的索引下标访问功能

我们当然可以在一切这样的场景下先把Collection对象变成纯数组，但这会使得应用系统变得非常复杂，我们使用Collection是希望使用它的变化通知的相关事件，转为纯数组会失去这一功能，或者会变成每次收到集合变化时再转一次纯数组交给etpl

我总结了一下几个知名库的封装数组类的接口：

• backbone.Collection：有.length属性，有each和forEach方法，使用at(index)访问元素
• ember.Array：有.length属性，有forEach方法，使用objectAt(index)访问元素
• ko.ObservableArray：有.length属性，能直接下标访问
• jQuery：有.length，能直接下标访问

我们的emc.Collection有.length属性，没有任何遍历的方法，使用get(index)访问元素

因此我希望可以支持这一类的封装数组，从上面来看，大家都会有.length属性，但访问方法各不相同，其中以each和forEach最为通用，emc可以添加该方法作支持

个人的建议是当具备.length属性时，增加检测forEach及each方法，存在的话也认为是一个数组并使用方法进行循环

最终这一需求会影响多少的体积，是否合适，还是交给 @errorrik 来判断吧

[errorrik]

好像很多没有each的。each和forEach的参数貌似也不尽相同？

[errorrik]

或者，data getter？

[otakustay]

用getter会导致数组不做复制操作，在操作比较频繁且数组较大时我担忧性能会覆盖掉etpl辛苦优化出来的收益

如果在循环数组xxx时，会触发xxx.0这样的getter的话，倒是不会有性能上的影响，不过现在并没有

Best regards

Gray Zhang

在 2015年3月26日 上午8:02:06, errorrik (notifications@github.com) 写到:

或者，data getter？

—
Reply to this email directly or view it on GitHub.

[errorrik]

在操作比较频繁且数组较大时我担忧性能会覆盖掉etpl辛苦优化出来的收益

这个倒不会。

建议使用data getter，而不是etpl本身去支持的原因是，各框架对Collection实现的api不尽相同，而且这事也不是标准的，所以都支持就没边了。另外一个问题是，属性访问的方法为啥不放在engine上呢？因为未来哪天支持预编译呢。

不过现在data getter功能的逻辑还比较弱，估计没法完全满足你的需要。你连续提了两个对于动态数据的需求了。所以这方面可以考虑做一些增强。我找找看谁有兴趣写的

[otakustay]

我主要考虑在（不久的）未来双向绑定必然会是一个需要做的事，如果模板无法支持动态数组的绑定的话，双向绑定可能会需要一个专用的模板来支持了

当然很有可能就算etpl支持动态数组，双向绑定本身还是需要一个特定的模板，如保存Watch Expression能支持更新等功能……

Best regards

Gray Zhang

在 2015年3月26日 下午1:57:10, errorrik (notifications@github.com) 写到:

在操作比较频繁且数组较大时我担忧性能会覆盖掉etpl辛苦优化出来的收益
这个倒不会。

建议使用data getter，而不是etpl本身去支持的原因是，各框架对Collection实现的api不尽相同，而且这事也不是标准的，所以都支持就没边了。另外一个问题是，属性访问的方法为啥不放在engine上呢？因为未来哪天支持预编译呢。

不过现在data getter功能的逻辑还比较弱，估计没法完全满足你的需要。你连续提了两个对于动态数据的需求了。所以这方面可以考虑做一些增强。我找找看谁有兴趣写的

—
Reply to this email directly or view it on GitHub.

[Justineo]

不如可以传 iterator 给 engine？

[errorrik]

当然很有可能就算etpl支持动态数组，双向绑定本身还是需要一个特定的模板，如保存Watch Expression能支持更新等功能……

双向绑定本身要求对视图进行解析和索引，并且能和数据对应上。我觉得，考虑这么多的话，就不是etpl要做的事情了。如果哪天要玩双向绑定，我觉得需要重写一个模板引擎，当然它的语法可以和现在有一部分是一样的。

不如可以传 iterator 给 engine？

现在filter在engine上已经让预编译很头疼了，所以现在不期望让compile的结果function依赖于engine才能exec