Create simple abstract class which encapsulates algorithm visiting tree. It will implementing require few method: getChildren, getParent, etc
grammar library will implement ANTLR functionality on top of this.
Create simple abstract class which encapsulates algorithm visiting tree. It will implementing require few method: getChildren, getParent, etc
`grammar` library will implement ANTLR functionality on top of this.
Inner visitor will be just BFS/DFS with skip(1), nothing more.
We should expect at least two accessor interfaces:
TreeIterator
getNode() => node
getParent() => TreeIterator
getChildren() => CQuery
TreeIterator sequential()
TreeIterator paralell()
TreeVisitor
visit(Consumer)
visitParent(Consumer)
visitChildren(Consumer)
TreeVisitor sequential()
TreeVisitor paralell()
We should implement at least two strategies:
- BFS
- DFS
Inner visitor will be just BFS/DFS with skip(1), nothing more.
We should expect at least two accessor interfaces:
- TreeIterator
- getNode() => node
- getParent() => TreeIterator
- getChildren() => CQuery<TreeIterator>
- TreeIterator sequential()
- TreeIterator paralell()
- TreeVisitor
- visit(Consumer<node>)
- visitParent(Consumer<TreeVisitor>)
- visitChildren(Consumer<TreeVisitor>)
- TreeVisitor sequential()
- TreeVisitor paralell()
Both strategies should offer configuration to stop recursive visits without filtering out nodes itself. That means, before creating CQuery, which offers only filtering out leaf results, we should support something like CTreeQuery, with additional methods like: dontRecurseIf (of course name should be better)
Both strategies should offer configuration to stop recursive visits without filtering out nodes itself. That means, before creating CQuery, which offers only filtering out leaf results, we should support something like CTreeQuery, with additional methods like: `dontRecurseIf` (of course name should be better)
bardzo bardzo pod znakiem zapytania, czy to trzeba generalizować w taki sposób? Po co? ANTLR w praktyce nie skorzysta z 99% funkcjonalności, XMLElement tak samo, innych tree nie będziemy wpinać. W praktyce każde tree ma jednak swoją strukturę i optymalizacje dot. zawartości, nie ma sensu robić ogólnego iteratora.
Na przykład wszystkie kryteria w ANTLR (po typie, po atrybutach) nie będą sprawdzane liniowo warunek po warunku, tylko mapowane in that or another way.
bardzo bardzo pod znakiem zapytania, czy to trzeba generalizować w taki sposób? Po co? ANTLR w praktyce nie skorzysta z 99% funkcjonalności, XMLElement tak samo, innych tree nie będziemy wpinać. W praktyce każde tree ma jednak swoją strukturę i optymalizacje dot. zawartości, nie ma sensu robić ogólnego iteratora.
Na przykład wszystkie kryteria w ANTLR (po typie, po atrybutach) nie będą sprawdzane liniowo warunek po warunku, tylko mapowane in that or another way.
Create simple abstract class which encapsulates algorithm visiting tree. It will implementing require few method: getChildren, getParent, etc
grammarlibrary will implement ANTLR functionality on top of this.We should implement at least two strategies:
Inner visitor will be just BFS/DFS with skip(1), nothing more.
We should expect at least two accessor interfaces:
Both strategies should offer configuration to stop recursive visits without filtering out nodes itself. That means, before creating CQuery, which offers only filtering out leaf results, we should support something like CTreeQuery, with additional methods like:
dontRecurseIf(of course name should be better)bardzo bardzo pod znakiem zapytania, czy to trzeba generalizować w taki sposób? Po co? ANTLR w praktyce nie skorzysta z 99% funkcjonalności, XMLElement tak samo, innych tree nie będziemy wpinać. W praktyce każde tree ma jednak swoją strukturę i optymalizacje dot. zawartości, nie ma sensu robić ogólnego iteratora.
Na przykład wszystkie kryteria w ANTLR (po typie, po atrybutach) nie będą sprawdzane liniowo warunek po warunku, tylko mapowane in that or another way.