AnyElemApi
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).
This element itself.
Super-trait for all element query API traits, promising a self type.
Simplicity and consistency of the entire query API are 2 important design considerations. For example, the query API methods themselves use no generics.