Ext 2.0 for JSVM

A.js:
一个方法中调用了new B();
B.js:
一个方法中调用了new A();
那么A.js中应该$import B，而B.js中应该$import A。这就是一个回环。如果以A为入口，当然不需要在B中$import A，则不存在回环；反之也一样。但是作为类库很难避免究竟以A为入口还是以B为入口吧。如果避免不了回环，那打破回环继续加载，可能会更好。
----------------------------------------------------------
其实这种逻辑实际上是有问题，一般写代码不会写成这样，但作为个有趣的例子，在处理循环Import上，在我的处理中，只是简单地按A,B顺序加载，或A里面Import B,就只看那个先被加栽，后加载里的$import("A")会被忽略，因为classloader发现已存在A。

但是异步加栽还是有必要实现的，有他的应用场景，我现在在改EXT的Desktop中，作为OAOP应用，点了菜单项后才去读取js执行，这个时候同步会是可比较差的用户体验，而简单地处理成如下就会好很多

我的异步函数定义：
$require(cls,callback,notify)

$require(moduleScript,function(){
   //执行加载的module,开启windows
  ...
},
function(state){
   //抛出事件让桌面显示异步加载module进度条
   this.fireEvent("ModuleloadStateChange",state)
}
)

要么jsvm和jsi的两位老大牵头，至少达成接口上和js目录组织方面的共识，形成一份书面的东西，将来大家用这些接口或者自己写类似轻量级framework的时候可以参考？

我觉得要实现动态加载，在代码中应该使用Factory模式，不要直接new一个class,所有class的获得都应该通过Factory,这样的话，如何加载javascript可以在工厂中实现，或缓存，或同步，或异步，或使用哪一个第三方库，都可以随时在工厂中切换。

js 也能实现这样的依赖？？

类似于spring ?

非常好的主意，能尽快出台就好了

貌似jsvm里支持 Class.forName(className).newInstance(arg ...) 实现类似功能

个人比较倾向于jsvm的方式，在服务期端组合，然后加载。至少让多个js小文件的情况下减去了很多次来回的交互。

但是，这种依赖关系的建立要写在所使用库的文件上面的方式可真是有点过头，可以说是侵入性太高了。另外，例如，现在Ext的RC1出来了。我要重新整理其中的依赖关系也是个麻烦事。所以还是期待有高手搞一个自动建立依赖关系的工具出来。同时如果能不把依赖关系放到目标库文件中，就舒服多了。

PS，楼主的例子，里面的整个Ext包下的东西都是从源代码整理过来的吧。佩服。

重新整理Ext的代码没有那么复杂，也没有什么工作量。
对Ext的代码只做了两件事，其余的未作改动：

1. 严格按照一个“类/对象”对应一个相同名称的文件的方式保存。
注：Ext source 目录下的大部分代码也这样做了，但不够彻底。Ext常把几个耦合关联比较紧密的对象定义在一个文件中，而且文件名也没有严格与之对应上，于是便多了一些混乱。其实它完全可以把这个对象名称和文件名称严格对应上，同时也便于维护。多切分几个文件并没有什么关系，Ext本身也是build打包之后才运用到工作环境中的。另外，Ext为了书写上的简洁方便而给“类/对象”取“别名”，我个人觉得这是得不偿失。源代码书写规范，容易读懂和维护，比多几个字节少几个字节要重要得多。代码压缩是其它层面的工作。

2. 模块头部加入一些依赖声明 ($import)。
注：模块对其它模块的依赖关系只有它自己知道，理应当在模块内部定义。

wch3116 , 取“别名”的一部份原因是向后兼容。

“一般代码不写成这个样子”，实际上有不少情况就是这个样子，存在回环。如果你使用Java的OO思想来写类库的话，应该会碰到不少。

“因为classloader发现已存在A”这种说法，已经带有一定的破除回环算法在里面，不过AB两个类相对来说简单，多几个类九不能简单地说“发现”了。在B尚未被import完毕，A可能是不能被表示为已经存在的。