关于[面向集合的框架设计]的一些说明

我习惯于概念层的推演，而且所阐述的东西多数是我们创造过程中的副产品，与业内常见的观念实际上是有着很大差异的。感觉不明白是因为你没有采用类似的视角，或者还没有独立思考过很多问题。如果你只是从业内已经熟知的概念出发试图理解我所写的内容，显然是不可能的事情。所以我常说know something already known.

如果你在编制一个新的应用，存在大量代码可能是

myFunc(){
  for each x in set
    doSomethingValuable(x);
  return packedResult;
}

myOtherFunc(packedResult){
  for each y in pakedResult
    doSomethingOther(y)
}

其实我们真正关心的是循环内部的某个过程，但是我们经常可以观察到它们被某些通用的或者特定的循环（集合遍历）操作所包围着。Witrix的设计方式是强调业务关注点，而把所有的汇总操作尽量抽象完成。比如现在界面上显示一些字段。从抽象的操作上说

  for each field in dsMeta.viewableFields
    show field.viewer

这一过程在平台代码中实现，它是一个通用的集合操作过程。不同的具体应用只是关心具体字段的展现形式，虽然我们必然需要字段集合，但是它不是我们注意力的重心。
  如果考虑到字段在界面上展示有一个布局问题，我们所要修改的是集合内部的结构方式：

  某种结构循环方式（dsMeta.字段组成的布局集合）
    show field.viewer

抽离出集合，实际上是在最大限度上分离结构问题和内容问题。    
   结构是可抽象的，是具有独立意义的。这就是Witrix所提出的面向结构的设计视角。不是强调对象的所谓业务含义，不是强调某种通用语言（例如ruby）的灵活的语法结构。在这之间存在着厚重的具有物理意义的可以进行结构分析的技术层。[url]http://canonical.iteye.com/blog/60758 [/url] http://canonical.iteye.com/blog/126467

stream style就是向流中不断追加内容，o.put(y).put(z).put(t)这种方式，看一下jQuery的代码就知道了。

SAX的事件驱动方式结合模式匹配能力确实可以直接在局部应用转换逻辑，但是缺乏状态空间的配合，它面对复杂问题时是乏力的。