[
Lists Home |
Date Index |
Thread Index
]
Burak Emir wrote:
> There are tons of things that one would like to do with an XQuery
> expression in Java, not just ship them to the database. In some sense,
> the discussion about analyzers, optimizers, debuggers all makes a case
> for a having a high-level model of queries.
Your argument seems to boil down to the idea that compilation will
always have certain advantages over interpretation, a widely held view.
People who lived through the history of embedded SQL are unlikely to be
convinced, as you are just echoing the arguments made decades ago in the
SQL context - and string APIs by and large won out - in part because
they can proliferate most rapidly in a wide variety of host languages.
But even in the abstract, the counterpoint is that interpretation will
always have certain advantages over compilation. For example, a query
engine is by nature an interpreter, no matter what you put in front of
it. Engines that require time-consuming optimization passes tend not to
succeed commercially, so providers learn to deliver good performance in
real time. The best argument for compilation is strong typing and early
error detection, but the relative value of this vs. good, continuous
testing is still debated in circles that favor interpreted languages.
And strong typing doesn't address the real problem at all - that the
database schema can change, invalidating existing programs that use it.
Recompilation and/or retesting of all such programs is required in
either case.
Last but not least, JSR 225 presents a proposal for a string-based API.
Where is the proposal for an API requiring language changes?
Bob Foster
http://xmlbuddy.com/
|
