Yan Container beta 1 发布

firebody，问得好！我就接着机械翻译：

YanContainer global = new DefaultContainer();;
global.registerComponent("aaa", ...);;


YanContainer local1 = new DefaultContainer();;
local1.registerComponent("ccc", 
  Components.bean(Class.forName("BeanC"););
    .withProperty("a", Components.useKey("aaa"););
    .withProperty("b", Components.useKey("bbb"););
    ;
local1.registerComponent("bbb", ...);;


YanContainer local2 = new DefaultContainer();;
local2.registerComponent("ccc", 
  Components.bean(Class.forName("BeanC"););
    .withProperty("a", Components.useKey("aaa"););
    .withProperty("b", Components.useKey("bbb"););
    ;
local2.registerComponent("bbb", ...);;


//NOTE, HERE!
YanContainer system1 = local1.inherit(global);;
YanContainer system2 = local2.inherit(global);;

global, local1, local2是三个各自独立的容器。
local1.inherit(global)产生一个虚容器，它让local1里面的组件可以看见global的内容。但是global看不见local1的。
同理，local2.inherit(global)又产生一个虚容器。

这样，操作system1, system2，你就可以得到互相关联又独立的容器体系。
比pico灵活多了。

其实要感谢readonly，这个缺省值的问题不仅让我补上了一个缺口，还发现了一小片新天地。

现在，我除了optional property，也支持optional parameter。
甚至，还可以给某个参数或者property指定缺省值。

比如：

Component c = 
  Components.ctor(A.class);
  .withDefaultValue(0, Components.value("the default value"););
  .optionalParameter(0);;

呵呵，当parameter 0解析失败，容器会用"the default value"来作为缺省值。

MonadPlus也实现了。现在可以在一个component失败的时候采用另一个继续进行了。

比如，现在可以指定一个Component是optional的。
比如：

Component c = Components.useKey("xxx");.option("mydefault value");;

当xxx解析失败的时候，系统就会采用mydefault value来作为这个Component的返回值。

Beta 1.1发布。在
https://sourceforge.net/project/showfiles.php?group_id=135702

改进：
1。 增加了optional property, optional parameter。
2。 支持default parameter value, default property value。
3。 增加了Monad.mplus()功能。增加了Component.option()和Component.optional()功能。
4。作为参数的component不需要被注册进容器就可以参与lifecycle。
5。支持spring的byName功能，并且同时支持byDisplayName, byQualifiedName等能力。并且这种byXXX可以无限扩展。

接口变化：
Component接口增加了一个Context参数。


copyright也写好了。就剩下user manual了。

虚容器这块很象classloader的方式。

pico得容器体系才象class loader。
pico里面，一个容器要从哪个父容器继承是定死的，你继承了谁就是谁。
继承关系和容器本身内容是放在一起的。

而我的继承是活的。就象是积木。比如：

YanContainer a_inherit_b = a.inherit(b);;
YanContainer b_inherit_a = b.inherit(a);;

从a_inherit_b看过去，是a继承b。
从b_inherit_a看过去，是b继承a。

不管你怎么看，a和b本身都是雷打不动，互相没有关系。

横着比一下，似乎更接近于关系型数据库。数据之间的关系和数据是分开管理的。你可以任意地join两个table。可以任意地让两个容器互相继承。
而classloader或者是pico则象是网络形数据库，数据间的关系和数据是绑在一起的，并且是定死的。

没有任何意见可提了？可悲呀。这就是javaeye的水平？
批判jdon的那劲头呢？哪去了？
jaskell也许是太远离普通的java程序员了。但是大家平时不是动辄张口就是ioc container吗？
平时高谈阔论指点江山，真到较真的时候怎么全瘪了？难道大家都是仅仅停留在用用现成的有名的库的层次上？就是熟练使用api这种程度？

开坛讲学的高手们呢？博览各种OO名著的高人呢？robbin呢？dlee呢？potion呢？各位算是国内的顶尖高手了吧？以你们的水平不是一眼就看得出设计的瑕疵？

功能上的不完整也行，设计上的不合理也行，哪怕接口上的不方便也行，提出一个也能让人佩服你们不是浪得虚名！

我对IoC Container也只限于使用Spring的层次而已，没有能力提出更加深刻的问题。而且确实最近忙得很，一直未能有时间去看，况且我最近兴趣都在Flash RIA上。dlee最近忙和搞培训，potian忙着开公司赚钱，估计都不能来给你捧场了。gigix比较精通IoC，说不定有些见解。

用用也可以。如果不是蜻蜓点水那么用的话，也可以看看用法上功能上yan有什么是spring或者pico能做到而它做不到的。
或者也可以看看是否有你本来需要而spring/pico支持的不好的？看看yan是不是能够满足你的需要？

新写了一个FAQ。感觉熟悉pico或者spring的人应该能看懂。

很希望看到各大大对yan的code的看法。当然最好是ajoo自己吹嘘一番啦，这样才有靶子。

自己吹嘘？很好，我合作。
我也不说什么“最高水平”了，列出条条来。

1。代码尽量简单，每个函数都很小。超过二十行的函数都很少。没有超过50行的函数。逻辑也简单，基本上代码自己就注释了自己。
2。设计灵活，扩展性强。
3。没有过度设计，现存的抽象都是用的到的。
4。单一职责。一个模块只作一件事，而不是象pico那样混在一起。极少循环依赖。
5。基本上每个类的设计都是ioc。（也说明，ioc并不一定需要容器）
6。继承使用非常谨慎。
7。函数式组合子的设计让框架非常非常强大灵活。
8。Component对象都从Components类或者Monad类通过静态方法输出，具体实现类全部隐藏。你要找构造函数？门儿都没有。这是我一贯推崇的静态工厂方式。

大家逐个靶子批吧。

我倒是有几个地方感觉不是太爽，看看你们能不能看出来吧。