[
Lists Home |
Date Index |
Thread Index
]
i recently corresponded with a lisp user which was perplexed - if i
might rephrase his position in a diplomatic tone, by the xpath library
in cl-xml, which leaves this sort of interface as an "exercise" to the
application programmer.
after an exchange, we arrived at a two-function interface which they
found much more comprehendible: each and all. they have the same
signature:
(defGeneric all (node iterator consumer)
(:method ((node t) (path-expression string) (consumer t))
"compile the path expression and delegate to the all method
for a path iterator"
)
(:method ((node-or-node-set t) (iterator function) (consumer null))
"given a null consumer, return a function which accepts its
own consumer and
which generates all matching nodes from the the original
source"
)
(:method ((node null) (iterator function) (consumer null))
"given a null source and consumer, return a function which
generates all matching
nodes given its own argument node or node-set and consumer"
)
(:method ((node elem-property-node) (iterator function) (consumer
function))
"call the given consumer with the collected matching nodes
for the given iterator and source property node"
)
(:method ((node elem-node) (iterator function) (consumer function))
"call the given consumer with the collected matching nodes
for the given iterator and source element node"
)
(:method ((node doc-node) (iterator function) (consumer function))
"call the given consumer with the collected matching nodes
for the given iterator and source document"
)
(:method ((node-set list) (iterator function) (consumer function))
"call the given consumer with the collected matching nodes
for the given iterator and source node-set"
)
(:method ((node-set-generator function) (iterator function) (consumer
function))
"call the given consumer with the collected matching nodes
for the given iterator and a generated set of source nodes"
))
if one neglects the namespace bindings, the interface has a similar
intent.
one might consider, however, several details which distinguish it.
it provides a uniform means to specify the disposition for the results.
in java one could accomplish this with an additional appropriate
instance parameter where lisp uses a consumer function.
it permits both single nodes and sets as the source.
it either produces immediate results or produces intermediate data
which can be reused. the possibility to generate and reuse compiled
paths is without cost, there's no reason to preclude it. lisp offers
the possibility to return more than one value, which means it's
possible, for example, to save prepared paths as a side-effect.
it offers distinct functions to produces the results individually or as
a set. i'm not sure that is an advantage.
i suppose, in java it would look something like:
interface XPath {
void each (NodeOrSet, String, Map, Visitor); // prepares the path
and delegates->(NodeOrSet, XPath, Visitor)
XPath each (NodeOrSet, String, Map): // prepares and
delegates->(NodeOrSet, XPath)
XPath each (String, Map,Visitor); // prepeares and
delegates->(XPath, Visitor)
XPath each (String, Map); // prepares a path
which accepts both source and visitor
void each (NodeOrSet, XPath, Visitor); // visits each node
generated from the source
XPath each (XPath, Visitor); // etc
XPath each (NodeOrSet, XPath): // etc
}
On Saturday, Sep 20, 2003, at 20:07 Europe/Berlin, Bill de hÓra wrote:
>
> Hi,
>
> public interface XPath
> {
> List match( Node target, String xpath, Map namespaces );
> }
...
|
