[ExtensionFunctionDefinition.makeCallExpression] Constraints on ExtensionFunctionCall implementations
Added by Christophe Marchand about 2 years ago
Hello,
when creating an extension function, are there some constraints on ExtensionFunctionCall implementations ?
- may we cache instance ?
- should implementation be thread-safe ?
- ...
Best regards, Christophe
Replies (3)
Please register to reply
RE: [ExtensionFunctionDefinition.makeCallExpression] Constraints on ExtensionFunctionCall implementations
-
Added by Martin Honnen about 2 years ago
I painfully found out that implementing https://www.saxonica.com/html/documentation11/javadoc/net/sf/saxon/lib/ExtensionFunctionCall.html#copyLocalData-net.sf.saxon.lib.ExtensionFunctionCall- is important (but currently not taken into account in SaxonCS). On the other hand, I started with a Java example by Norm that didn't do it and seemed to get away with storing data in the FunctionCallDefinition class instead. I have so far not figured out whether that approach can break easily in e.g. Saxon EE and multithreading.
RE: [ExtensionFunctionDefinition.makeCallExpression] Constraints on ExtensionFunctionCall implementations
-
Added by Michael Kay almost 2 years ago
Firstly, for simple stateless "pure" functions, use the ExtensionFunction
interface in preference to ExtensionFunctionDefinition
/ExtensionFunctionCall
. If you need the more complex interface, it's usually because you want to capture context information, and if you're doing that then you will want to make sure that each function-call expression appearing in your stylesheet results in a new instance of the relevant ExtensionFunctionCall
being created.
However, if the only reason for using this API is because you want access to the dynamic context (e.g. the context item), then the ExtensionFunctionCall
object doesn't need to hold any local data which means you can safely use the same ExtensionFunctionCall
object each time. (But there's little performance benefit in doing so.)
As Martin says, if the ExtensionFunctionCall
holds local data then it's important to ensure that the copyLocalData
method is implemented.
To be honest, I'm reading the code right now and having trouble recalling why we actually need to copy the ExtensionFunctionCall
object when its containing expression is copied. Historically it's probably because ExtensionFunctionCall
implemented Expression
, and an Expression
can only have one parent in the expression tree, so it's always copied when doing things like function inlining. But I can't see why that applies to the ExtensionFunctionCall
object.
RE: [ExtensionFunctionDefinition.makeCallExpression] Constraints on ExtensionFunctionCall implementations
-
Added by Christophe Marchand almost 2 years ago
Not simple !
I need to access to xPathContext.uriResolver, that's why I use the ExtensionFunctionDefinition.
Thanks to both of you for your responses, it largely simplifies my code !
Christophe
Please register to reply