[ExtensionFunctionDefinition.makeCallExpression] Constraints on ExtensionFunctionCall implementations
when creating an extension function, are there some constraints on ExtensionFunctionCall implementations ?
- may we cache instance ?
- should implementation be thread-safe ?
Best regards, Christophe
Please register to reply
RE: [ExtensionFunctionDefinition.makeCallExpression] Constraints on ExtensionFunctionCall implementations - Added by Martin Honnen over 1 year 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 over 1 year ago
Firstly, for simple stateless "pure" functions, use the
ExtensionFunction interface in preference to
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
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
RE: [ExtensionFunctionDefinition.makeCallExpression] Constraints on ExtensionFunctionCall implementations - Added by Christophe Marchand over 1 year 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 !
Please register to reply