> One thing to note, in my implementation I actually support script > blocks in terms of processing instructions (PI) > > <?script > var foo = 1; > var bar = 2; > var cond = (foo < bar) && (bar - foo > 0); > ?>
Please don't make me reinvent this. If you send it, I will integrate it ASAP. My feeling is that adding a simple thing as ORs or ANDs to BSF is the beginning of a very slippery slope...by the time you are done you end up with XSLT. XSLT is great for pattern matching and tree manipulation, but as a programming language it leaves something to be desired. I very much want the BSF core to be free of all of this. People who don't need this stuff are not encumbered by it. Then I want an optional package which allows you to use the scripting language of your choice. At that point, you will be free to use all the facilities of that language. However, you will have to accept all that that implies. If you want to use VBScript and manipuate the Windows registry, then your build script will likely only ever run on Windows. And if you feel so inclined, you can even make the steps optional based on the value of various Java system properties. And I agree that a PI would be a more natural syntax for this in many cases. - Sam Ruby P.S. CDATA can also be used to avoid the need to subsitute entity expressions for operators. P.P.S. BSF will either become open source, or I will die trying. I'm meeting again today with the IBM lawyers.
