面向能力方法的实现-XPL还是StandinPattern

进一步规划Ablever中面向能力的实现方式以后发现, 原来通过Ablet/Caplet和通过替身模式是两种完全不同的实现方式. 前者是要实现一个可以扩展的编程语言 eXtensible Programming Language, 主要在编译阶段实现能力逻辑的引入, 而后者是允许开发者还是用已经熟悉掌握的程序设计语言(java)来编写代码, 而在运行时通过动态生成替身类和对象实现能力逻辑的附着. 在最终理想的Ableverse系统中这两者方式应该兼而有之, 互补短长.

但是目前阶段不可能在短期内把这两种方式同时形成发展完善, 特别是XPL, 她需要相当数量的程序员用户群在相当长的时间内不断完善和改进模式和语法才能有竞争力, 但是从头开始的话, 要吸引这么多不错的程序员放弃他们已经熟悉掌握的基本语言, 化额外的时间和精力来习惯和忍受一个不成熟, 又没有方便开发的IDE的新语音的话, 想想都是不太可能的事情, 更别说让他们喜欢和出力发展这种语言了.

Standin模式似乎更容易实现和容易被接受一些, 但同时似乎也不如XPL强大和灵活, 有些调用似乎要用很拙劣的代码来表达, 让人不是很舒服. 但是比起完全从头学习和接受一门新语音来说, 我觉得她还是会比XPL更容易被接受, 只要她实现的功能够强大, 而且比其他框架和设计模式更简单.

XPL还有一个问题, 就是它可以基于, 也非常倾向于通过freemarker来实现, 而freemarker至今还没有考虑过对模板的预编译和编译结果的二进制存储, 当然, 这对于一种面向web的模板语言来说是天经地义的事, 她根本不需要考虑这些; 但是对于XPL来说, 这意味着她会没有编译形式的能力支持软件发行方式, 这在性能上的损失其实微不足道, 因为只不过稍稍降低了一点编译速度, 对运行没有任何影响, 但是对于商业能力提供者的版权保护会是一个大问题, 如果他不得不以源代码的形式发行能力库, 那么就意味着恶意者进行反向工程的难度比反编译没有经过混淆的java类还要容易. 这对平台本身的广泛应用是非常不利的. 这个问题最终可以通过对freemarker加入预编译模板的功能来解决, 而这实际上增加了XPL方式付诸实现的成本代价.

而且考虑到最好尽快商业化的问题, XPL的进程可能还是需要再推迟一些, 如果用替身模式能先完成 比较有商业价值的产品出来, 首先运作起来以后, 就可以有更大的人力物力投入到XPL上来了, 这样会是一个比较好的商业过程. 从XPL做起的话也不是不可以, 但那需要更长的孕育期, 做起来更辛苦, 风险也更大.