AnyElemNodeApi
Related Doc:
package queryapi
The ("stable") element type itself.
The ("stable") element type itself. It is not restricted in the query API traits (only indirectly, through ThisElemApi).
Concrete element classes will restrict this type to that element class itself.
Why do we need 2 type members ThisElem and ThisElemApi and not just ThisElem? Consider for example query method implementations in trait ElemLike. Had we used just one type member ThisElem (restricting it to be a sub-type of ElemLike), then a call of a function like findAllChildElems on another element would not return a value of the same type (ElemLike.this.ThisElem) according to the Scala compiler. To prevent the use of casts, we used 2 type members ThisElem and ThisElemApi instead.
Upperbound on type ThisElem, which must be restricted to a sub-type of the query API trait in question.
Upperbound on type ThisElem, which must be restricted to a sub-type of the query API trait in question.
Concrete element classes will restrict this type to that element class itself.
The purely abstract query API traits (XXXApi) should only restrict this type to a sub-type of the query API trait, without putting any further restrictions on the type. This way these purely abstract traits are easy to use as "generic" element contracts abstracting over multiple backing element implementations (for example, Saxon tiny trees and native yaidom elements) without "infecting" the client code with generics.
To a lesser extent, this should also be true for the partially implemented query API traits (XXXLike).
The node type, that is a super-type of the element type, but also of corresponding text node types etc.
This element itself.
This element itself.
Super-trait for all element query API traits that know about the node super-type.