眼下新的GUI Framework的第一版也就只剩下3个控件了。虽然之前说过要开发一个理论上是P2P上的远程对象交互协议、要开发一个窗口设计器、还要开发一个LALR Parser GUI作为GUI Framework的demo。我想这也是一个大的工程，对于我一个人来说。但是今天的一个想法终于把这三个东西串了起来。

    想必大家MFC用得很囧吧。Linux下面开发C++反正所有选择相比起当年的Borland C++Builder来说都是很烂的，那就不说了。Windows下面开发C++是哭笑不得。C++ Builder虽然想法是好的，其实我也不介意他用Delphi的VCL，只是编译器的bug实在是太多了。新的C++Builder连试用版的安装程序都有问题，于是彻底失去希望了。现在RAD也就剩下MFC一个了。说实话我以前做游戏、做软件渲染器到现在做编译器做什么什么的，实际上都是类似库或者是中间件的，跟RAD一点关系都没有。只不过我仍然非常喜欢RAD这样的开发方式。但是MFC那个样子实在是RAD不起来啊，所以我干脆揭竿而起，另做一个了。至于将来前途怎么样我就不管了，至少得先让自己爽起来再说。

    为什么我那么强调窗口设计器呢？其实可以大家可以开个C#，尝试做一下我以前那个破IDE的界面。这样的话窗口设计器会给你一份代码，藏在XXForm.Designer.cs底下，然后写几行代码把东西当prototype跑起来。然后你再用MFC做一遍。现在VC++ 9.0对MFC的支持其实也是很漂亮的，只不过量变引起不了质变而已。做完了之后比较一下哪个比较囧（指的仅仅是开发过程，不要拿效率说事儿，那点破界面慢一点无所谓）。

    现在我揭竿而起重头来了一次，就等于给你.NET的System.Windows.Forms一样，有类库没有界面编辑器。如果你想做一个界面出来的话就要自己亲手写一个XXForm.Designer.cs出来。这个其实比MFC更囧，也令我自己更加不爽。要是我自己做的东西连我自己用着都不高兴的话那就太没意思了，所以得来一个那样的设计器才行。

    话说到这里，其实VL++这套类库（除了GUI还有很多其他东西，用了的话连STL都免了）文件结构复杂，每一次使用都要重新一个一个添加，也是很不爽的。因此至少窗口设计器也要自动把这些该加进去的文件添加到vcproj不是么。但是VL++并不仅仅是一个GUI Framework啊，至少还能写编译器是吧。自己做了一个Syngram，直接在C++里面写左递归文法，用起来也挺爽的。当然爽不是爽在能写文法，而是爽在这样做，编译器遇到了大的变化也非常容易改，传说中的解耦啊。Vczh Free Script 1.0只是一个支持闭包的东西，后来大刀阔斧修改了，就变成同时支持很多个编程范式的脚本语言了。多亏了Syngram啊，改语法真是不费吹灰之力。既然我要弄一个GUI工具来写编译器，那么吧两个工具整合在一起，就是一个很自然的想法了。再加上未来有空的话还要做一个远程对象交互协议，也是很需要GUI工具帮忙的。

    于是呢，虽然工程量很大，但是我们来展望一下。现在，自己需要开发一个系统的客户端，这个客户端需要跟远程的数据库打交道，同时还要支持大量的配置。那怎么办呢？首先，打开这个工具，连接到一个刚刚建立好的vcproj上面，然后就拖控件了。拖完了之后就是一个prototype了，一跑觉得不错。现在，从远程的机器那边拿到一个使用远程对象交互协议的接口说明，添加到这个工具里面，这个工具就自动产生了客户端的代码，让你可以像调用一个类一样跟远程的机器打交道（像SOA？我觉得不像，我也不想像。像WCF？虽然概念类似，不过既然我不做SOA，那就不像了）。最后一步要配置。现在配置都写DSL啊。所谓的DSL就是面向特定领域的特殊语言。编译器不会写？没关系，还是那个工具，新建一个编译器，拖几个文法出来，搞一搞，呀，代码出来啦。用这个生成以后的代码写写后端，一个DSL就有啦。

    嗯嗯，虽然很理想化，但至少这玩意儿作为一个原型存在，也是挺好玩的。不过呢，可能要花很长时间，这个计划也不是稳定的，得看未来发生了些什么事情。不过最少那个做编译器的玩意儿还是要的。ANTLR这个LL(k)都有了，我Syngram好歹也是LR(k)，不做就不爽啦。