眼下新的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連試用版的安裝程序都有問題，于是徹底失去希望了?，F在RAD也就剩下MFC一個了。說實話我以前做游戲、做軟件渲染器到現在做編譯器做什么什么的，實際上都是類似庫或者是中間件的，跟RAD一點關系都沒有。只不過我仍然非常喜歡RAD這樣的開發方式。但是MFC那個樣子實在是RAD不起來啊，所以我干脆揭竿而起，另做一個了。至于將來前途怎么樣我就不管了，至少得先讓自己爽起來再說。

    為什么我那么強調窗口設計器呢？其實可以大家可以開個C#，嘗試做一下我以前那個破IDE的界面。這樣的話窗口設計器會給你一份代碼，藏在XXForm.Designer.cs底下，然后寫幾行代碼把東西當prototype跑起來。然后你再用MFC做一遍?，F在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工具幫忙的。

    于是呢，雖然工程量很大，但是我們來展望一下?，F在，自己需要開發一個系統的客戶端，這個客戶端需要跟遠程的數據庫打交道，同時還要支持大量的配置。那怎么辦呢？首先，打開這個工具，連接到一個剛剛建立好的vcproj上面，然后就拖控件了。拖完了之后就是一個prototype了，一跑覺得不錯?，F在，從遠程的機器那邊拿到一個使用遠程對象交互協議的接口說明，添加到這個工具里面，這個工具就自動產生了客戶端的代碼，讓你可以像調用一個類一樣跟遠程的機器打交道（像SOA？我覺得不像，我也不想像。像WCF？雖然概念類似，不過既然我不做SOA，那就不像了）。最后一步要配置。現在配置都寫DSL啊。所謂的DSL就是面向特定領域的特殊語言。編譯器不會寫？沒關系，還是那個工具，新建一個編譯器，拖幾個文法出來，搞一搞，呀，代碼出來啦。用這個生成以后的代碼寫寫后端，一個DSL就有啦。

    嗯嗯，雖然很理想化，但至少這玩意兒作為一個原型存在，也是挺好玩的。不過呢，可能要花很長時間，這個計劃也不是穩定的，得看未來發生了些什么事情。不過最少那個做編譯器的玩意兒還是要的。ANTLR這個LL(k)都有了，我Syngram好歹也是LR(k)，不做就不爽啦。