Reece Dunn wrote: > Dave Abrahams wrote: >> Rene Rivera <[EMAIL PROTECTED]> writes: >> >>> David Abrahams wrote: >>>> (in Python of course -- a much better language for ASTs than >>>> C++ because of their very dynamic structure). >>> Not that I disagree with that. But I think preferring more than one >>> language, I'm counting the C++ implementation, is going to be >>> detrimental to the eventual flexibility of quickbooc. After all I >>> might want to use Lua or PHP, also languages well suited for dynamic >>> nature of ASTs. >> Sorry, I don't get it. You can always use a Python backend that >> writes XML and read that in with Lua or PHP as you're suggesting >> below. It sounds like you're saying that, because someone might be >> interested in any number of different languages that are superior to >> C++ for doing this backend work, we should stick exclusively to C++, a >> language that's inferior for this sort of work.
I don't think I was saying that :-( I did somewhat imply that integrating C++ with other systems is easier than integrating, for example, Python and PHP. I.e. it would be easier and considerably safer to make a quickbook PHP module than it would be to have PHP run Python. > This essentially comes down to where in the QuickBook processing you want > to run the extended functionality. The current implementation is a good > QuickBook -> DocBook translator. It currently provides basic transformation > and manipulation facilities via macros and the new template feature. Yes. And it was my understanding that quickbook currently makes use of some assumptions given that the output will be processed by a docbook processor. Not sure what those are as Joel wasn't specific when he mentioned it to me. > What you are wanting is the ability to hook into the QuickBook processor > as it is transforming the document and provide powerful scripting where > you need to extend the QuickBook facilities -- sort of like uber-templates :). Not sure if that's what we all want ;-) I should come clean and mention what I currently want... I have a use I want to put quickbook to. I need/want to use the quickbook syntax within a wiki context. This comes from evaluating the variety of wiki formats and realizing that they just plain suck. The structuring features of quickbook alone blow away any current wiki format. So ultimately I want a quickbook library I can plug into a web server, either directly or through PHP, to translate from user edited quickbook content to XHTML fragments, as fast as possible. But to put it closer to "home". It would really cool if the officially supported Boost wiki used quicbook content. Also it would be nice to be able to dynamically present Boost documentation on the website without having to go through the slow docbook translation and check in into CVS. >> In fairness, my suggestion does impose the requirement to have Python >> installed, even on developers who aren't interested in Python, but >> doesn't everybody have Python already? ;-) > > Most people who use Boost, but not everyone. And more likely the decision of what tools to use are not up to the developer. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo _______________________________________________ Boost-docs mailing list [email protected] Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs
