循环依赖
循环依赖是非常必要的，有的程序写着写着就循环依赖了，可以提取出一个对象来共同依赖解决循环依赖，但是有时会破坏程序的逻辑自封闭和高内聚。所以没解决好循环依赖的模块化库、框架、编译器都不是一个好库、框架、编译器。
kmdjs 的本质就是 {}，从 {} 扩展出的 tree。从很早的版本就开始，是支持循环依赖的。比如下面的代码：
会被 kmdjs 编译成：
要支持循环依赖其实有个要求，就是 lazy using。不是 lazy using 的循环依赖是无解的循环依赖。
怎么理解上面这句话呢？看上面的代码，Class.extend 执行完之后，各自依赖的东西是不会被调用的。
A 代码里的 new namespace2.B() 要在 new namespace1.A 的时候才会被调用。
B 代码里的 new namespace1.A() 要 var a = new namespace1.A;a.xx() 之后被调用后才会被执行。
所以在初始化阶段，这样的循环依赖是被允许的，因为都是 lazy using。只要满足 lazy using，执行顺序就不重要了，如果不是 lazy using（如静态属性方法的设置），执行顺序就必须把依赖的项先执行。
如上面所说，不是所有的循环依赖都能够解决的，比如看 C#里面的无解的循环依赖的例子：
上面的代码编译时候就会报错。怎么改成有解，那么就要 lazy using：
这样的依赖编译器是可以解决的。
kmdjs 0.1.4
kmd 的意思是 kernel module definition。该版本和以前的主要变化如下：
- kmdjs 文件大小从以前的一万多行代码变成了一百多行代码
- 从以前的 namespace+class 组织项目变成 namespace+module 组织项目
kmdjs API
kmdjs.config
用于配置 namespace + module 和文件路径的 mapping
kmdjs.main
程序的入口代码。
kmdjs.define
定义模块
如果只传两个参数，代表不依赖任何模块。这里和 AMD 一样，在 factory 的回调里把依赖注入到里面。
但是也直接在代码里把 namespace 写进去访问，如下所示：
而有的时候必须使用上面这种方式用来解决循环依赖导致执行顺序问题带来的注入 undefined：如：
和
bundler
可以通过 main 传入回调函数，在回调函数中拿到编辑打包好的字符串。
如上面的例子打包出来的代码：
极乐网 2016 年 8 月 30 日
沙发！！！！！！！！！！个人建站，做技术问答的，目前最火的是前端领域，欢迎一起交流！——http://www.dreawer.com