好文章，收了，谢谢博主

麻烦大神给我发一份源代码吧，最近在研究GUI，做的太强大了。有点着急。
邮箱：1536012451@qq.com

能不能把源代码发我一下，我想学习学习，谢谢
tzh8478@163.com

不知道你那个Witrix，，商业上发展得如何。

我曾参与创建过一个属于找死型的国内做通用开发工具的公司。虽然后来痛感国内通用软件市场的腐烂转而做起了电子行业，不过关于开发工具和语言的思考一直没有停止。

和这里的人相比，我对现在这些新的语言和发展有些隔膜了，不过很多东西由于能和我的思考对应上，虽然缺少实践也能理解一二。

在你的文章中看到了不少同感，尝试做点交流，虽然很难互相理解，但我可以尝试表达一下：

1 受到认识论的一些启发，我想我们首先应该将软件开发的过程定义为一个科学发现的过程，一个通过理性分析建构逻辑模型的过程，是在理论-事实的迭代中逐渐完善的。这一点已经是共识，但目前的工具尚未对这个过程提供完好的支持。这我们可以从系统重构时程序员大量的查找替换拷贝粘贴就可以看出来。

2 不能以轻视的态度看待所谓的语法糖，抛开OO的所谓哲学，仅仅把那些所谓的抽象看作语法糖。其实没有什么抽象的概念，当我们说“继承”，其实只不过是在说一段代码，而且一般来说是在设计时运行的代码罢了。如果“继承”代码在运行时运行，那就变成了一种具有病毒特征的高效的动态语言。

3 设计时与运行时的关系，尚未得到彻底的分析，我想一旦深入理解了这种关系，所谓静态语言与动态语言的鸿沟就不复存在，我们可以在效率与灵活性之间从容取舍。

4 再来看所谓的现代开发工具对效率的要求不高的说法，也是有前提的。我们只不过感受不到效率的限制而已。事实上，对效率的要求，已经使我们被迫放弃一些看起来优雅的设计。举一个极端的例子，在位图编程中，我们无法把单独的像素看作一个一个的对象，即使这可以让程序看起来简单。如何让优雅与高效并存，也是一个不小的课题。虽然完全并存是不可能的，但我以为现有的语言在这方面的提升空间还相当大。

5 程序员之间的交流，文档是靠不住的，唯一靠得住的就是代码，包括静态的，尤其是动态运行的。未来的开发工具应该正视这个问题，为程序员之间的交流提供优秀的方案，这看起来是提高团队工作效率的最有效的方法了。举一个另类的例子，可不可以在一段代码上附加一个录音注释呢？

6 AOP所揭示的是一个方向，但目前做得远远不够。设想一下我们在设计程序的过程中头脑中浮现出来的各种隐喻，指导我们敲下代码的头脑中的模型。当我们对接班的程序员介绍的时候，是先给他讲这些隐喻，模型更有效率呢，还是直接看一段糅合了N个思路的代码更有效率？其实，在浏览代码时，我们也只能通过恢复设计者的数个思路来理解，而不是直接通过代码来理解。

7 让用户编程，似乎是个疯狂的想法，但在某些时候，编程比操作按钮来得更加友好。以此为思路，任何软件都是一个自开发的工具。

8 大教堂与市集的愿景是好的，但缺少一条最根本的东西，商业利益驱动，不同于那些软件共产主义分子，我认为一个灵活的市场机制，是发挥每个人效能的最佳环境。我们未来应不必在opensource和closesource之间进行取舍，这也是开发工具所应支持的。

9 在一个复杂的继承关系中，基础类的修改往往意味着新产生无数的Bug。其实，如果在运行时引入版本概念，我们往往可以对系统进行细微的，不那么符合OO的小修改，但是却能很好的工作，也能很好的理解。至于不符合审美的问题，如果是工程，那么就此结束，如果要复用，那么再继续调整。OK，这里谈到我的一个核心概念，把继承当作版本来处理，版本管理所能处理的要更加广泛灵活，而继承只不过是一个特例的应用而已。

"寻找的顺序是一种向上迂回的思想，即如果本级别找不到，就只能去本级别之上的找，不会向下寻找"

是反过来的吧？类的查找应该是上往下查找的吧，否则会出现安全问题。

这么多人都要，我不要实在是过意不去．呵呵
goujun_1982@hotmail.com
先谢谢了

准确的说，Student和Teacher并不能成为Person的子类。

受用

隐藏域是正解，
不过你可以查查Struts2的源代码看看解析标签form的action时是如何处理的，再看看还有没有另外取值的方式，不用<%=%>这种形式。

好像有好几个用Java写操作系统的项目
以前见过

manifest可以解决问题，但是也有路径限制问题。
不过如果命令行限制了长度，可以通过多个命令将jar包分别设置到classpath当中去

时刻关注

英文和中文可以给我发一份吗?
thinking_chou@126.com
.谢谢

我也想要一本,英文和中文都要.谢谢