Module xl.compiler
Package de.grogra.xl.expr

Class GetPattern

java.lang.Object
de.grogra.graph.impl.Edge
de.grogra.graph.impl.Node
de.grogra.xl.expr.Expression
de.grogra.xl.expr.EvalExpression
de.grogra.xl.expr.GetPattern
All Implemented Interfaces:
Manageable, PersistenceCapable, Shareable, TypeId, UserFields, XObject, Map, Completable, ExpressionFactory, LocalAccess, ValueObserver, Serializable, Cloneable
public final class GetPattern extends EvalExpression implements LocalAccess
First I though I could remove the local/ var declaration for the pattern serialization (as the pattern is not run directly but used in a query - which can (and need to) declare the q variables for this pattern. But then, subroutine (used in transitive patterns for instance) would not work. Thus, back to serializing the pattern as if it is a query. Pattern are stored almost exactly as QUERY, They simply are initialized in the CCLass earlier to ensure that they are init when the queries are initialized. This do not ensure that custom pattern are init when used in other custom patterns. Thus, nesting custom patterns is disabled. It the order of init, or a lazy init is added, it would enables the nesting of custom patterns. In the compound pattern collecting, there should not be issue to nest patterns.
See Also: