Eric Niebler wrote:
I'm kick-starting the development effort to reimplement Phoenix on top of Proto. There's already been some discussion off-list among the interested parties, but there was general agreement to move the discussion here to do our work out in the open and possibly involve more people. To that end, I have ...
... created a Wiki page for coordinating our efforts: https://svn.boost.org/trac/boost/wiki/BoostPhoenix3
... created a branch at branches/phoenix_v3. Anybody interested in helping out or just following along should do the following from BOOST_ROOT (trunk):
cd boost svn co https://svn.boost.org/svn/boost/branches/phoenix_v3/boost/phoenix cd ../libs svn co https://svn.boost.org/svn/boost/branches/phoenix_v3/libs/phoenix
There is nothing in boost/phoenix right now but stub headers, and libs/phoenix is simply copied from trunk/libs/spirit/phoenix.
On the Wiki I put uploaded a miniphoenix.cpp file that demonstrates some ideas I have about what Phoenix-on-Proto might look like. Feedback is welcome.
First of all, thanks for kick-starting the development, Eric! I looked at the prototype and it looks good. Reading the replies to this post, I'd not worry about compile time too much at this point but at least have a keen eye on it. I'd want to concentrate more on the extension mechanism and its interface. To Alp and the folks who came in later, let me explain... Quite distinguishable in libraries that I wrote (Spirit, Phoenix and Fusion), is that there are two APIs: 1) The user API and 2) the extension API. The user API is what the user normally sees. The extension API, is typically for advanced users. I as library writer am a prime client of the extension API. The entire library itself is built from that extension API. This is essentially the core/kernel of the library. Making this extension interface as simple and clear as possible, makes it is easier for other people to contribute code. It also makes it a joy to port. Ideally, if the proto port uses the same extension API as Phoenix-2, then all the modules above the core could, in theory, remain as-is. Alas, this is not possible due to a couple of reasons, but still, the extension mechanism made Eric's task easier (I would say) when he did the initial port to proto. Everything funnels through this extension API. Port it and everything else follows. At this point, I'd say that the design of the extension API is of most crucial significance. I'll have some feedback on this as soon as I learn more about the initial prototype. Those who have seen or used my other libraries' extension interfaces (Dan, Hartmut, etc.) please feel free to chime in. More to come... Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net