public class MemoClosure extends Closure
The MemoClosure is designed for use when the value is only read several times. The value is saved on the first evaluation and remembered for later use.
The MemoClosure maintains a reservoir containing those items in the value that have already been read. When a new iterator is requested to read the value, this iterator first examines and returns any items already placed in the reservoir by previous users of the MemoClosure. When the reservoir is exhausted, it then uses an underlying Input Iterator to read further values of the underlying expression. If the value is not read to completion (for example, if the first user did exists($expr), then the Input Iterator is left positioned where this user abandoned it. The next user will read any values left in the reservoir by the first user, and then pick up iterating the base expression where the first user left off. Eventually, all the values of the expression will find their way into the reservoir, and future users simply iterate over the reservoir contents. Alternatively, of course, the values may be left unread.
Delayed evaluation is used only for expressions with a static type that allows more than one item, so the evaluateItem() method will not normally be used, but it is supported for completeness.
The expression may depend on local variables and on the context item; these values are held in the saved XPathContext object that is kept as part of the Closure, and they will always be read from that object. The expression may also depend on global variables; these are unchanging, so they can be read from the Bindery in the normal way. Expressions that depend on other contextual information, for example the values of position(), last(), current(), current-group(), should not be evaluated using this mechanism: they should always be evaluated eagerly. This means that the Closure does not need to keep a copy of these context variables.
In Saxon-EE, a for-each loop can be multithreaded. If a variable declared outside the loop is evaluated as a MemoClosure, then a reference to the variable within the loop can result in concurrent attempts to evaluate the variable incrementally. This is prevented by synchronizing the evaluation methods.
depth, expression, inputIterator, savedXPathContext| Constructor and Description |
|---|
MemoClosure()
Constructor should not be called directly, instances should be made using the make() method.
|
MemoClosure(Expression expr,
XPathContext context) |
| Modifier and Type | Method and Description |
|---|---|
Item |
itemAt(int n)
Get the n'th item in the sequence, zero-based
|
SequenceIterator<Item<?>> |
iterate()
Evaluate the expression in a given context to return an iterator over a sequence
|
Sequence<Item<?>> |
makeRepeatable()
Ensure that the sequence is in a form where it can be evaluated more than once.
|
GroundedValue<?> |
reduce()
Return a value containing all the items in the sequence returned by this
SequenceIterator
|
getExpression, getSavedXPathContext, head, make, saveContext, setExpression, setSavedXPathContextclone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, waitasIterable, materializepublic MemoClosure()
public MemoClosure(Expression expr, XPathContext context) throws XPathException
XPathExceptionpublic SequenceIterator<Item<?>> iterate() throws XPathException
iterate in interface Sequence<Item<?>>iterate in class ClosureSequenceIterator, which is
not a Iterator) over all the itemsXPathException - in the situation where the sequence is evaluated lazily, and
constructing an iterator over the items causes a dynamic error.public Item itemAt(int n) throws XPathException
n - the index of the required item, starting from zeroXPathException - if an error occurs reading the base iteratorpublic GroundedValue<?> reduce() throws XPathException
reduce in class ClosureXPathException - if a failure occurs reading the inputpublic Sequence<Item<?>> makeRepeatable()
SequenceLazySequence and Closure can only be evaluated
once, and this operation causes these to be grounded. However, making it repeatable
is not the same as making it grounded; it does not flush out all errors. Indeed, lazy
evaluation relies on this property, because an expression that has been lifted out of
a loop must not be evaluated unless the loop is executed at least once, to prevent spurious
errors.makeRepeatable in interface Sequence<Item<?>>makeRepeatable in class ClosureCopyright (c) 2004-2020 Saxonica Limited. All rights reserved.