On Nov 8, 2005, at 9:49 PM, Stefan Seefeld wrote:
Douglas Gregor wrote:
This is probably the case. However, one can think of places where a tighter integration might give a more natural interface, e.g.,
xml::element_ptr books = ...; xml::node_set cheap_books = books[attr("price") < 30];
But, like the reader interface, a library that supports something DOM- like can be augmented with XPath support.
I'm not sure I agree. While the syntax you suggest above is quite cute, and probably follows the 'xpath object model' as implied by the XPath spec, the latter also specifies syntax, which your suggestion doesn't adher to.
We can't match the syntax precisely, of course, but we can apply a "similar" syntax.
So, while what you suggest may be useful in itself, it isn't really compatible with xpath. (Think of applications such as xslt processors, where xpath expressions are strings embedded into attributes.)
I wasn't actually excluding the use of strings as XPath expressions.
Note that my API already supports XPath. It may be a nice add-on to overload various operators for the xpath type to allow your suggested syntax, but I don't see this becoming really useful. It's just cute.
Have you perchance looked at Xpressive? The static constructs in it allow static checking of regexes (because they are built with C++ operators), whereas the dynamic (from-string) constructs allow one more flexibility. The same can occur with XPath: using some C++ operator overloading, we can have statically-checked XPath expressions that also provide more accurate type information (e.g., an element-set instead of a node-set). Of course, we'll always need to be able to fall back to strings as XPath expressions, which can only be checked at run-time. Doug