Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision Next revision Both sides next revision | ||
treex:api [2015/11/04 13:34] popel created |
treex:api [2015/12/13 23:56] popel |
||
---|---|---|---|
Line 1: | Line 1: | ||
Plánujeme nové API pro (nový) Treex. | Plánujeme nové API pro (nový) Treex. | ||
Mělo by jít implementovat ve více jazycích, sami bychom chtěli implementovat asi Perl, Python, Java, C++. | Mělo by jít implementovat ve více jazycích, sami bychom chtěli implementovat asi Perl, Python, Java, C++. | ||
+ | Implementační poznámky jsou zde [[treex: | ||
ref attributes: | ref attributes: | ||
Line 62: | Line 63: | ||
add_aligned_node | add_aligned_node | ||
update_aligned_nodes | update_aligned_nodes | ||
- | + | ||
- | | + | ===== Mají children/ |
+ | |||
+ | * Současné '' | ||
+ | * Pokud někdo bude to pole potřebovat (třeba proto, že chce strom měnit, ale toto pole má zůstat neměnné), tak to lze vždy snadno zařídit (v Pythonu '' | ||
+ | * Další výhodou iterátorů je, že někdy nepotřebuji ani projít všechny prvky toho pole, ale hledám první prvek, který splní nějakou podmínku (short circuit). | ||
+ | * Pokud by implementace měla ke každému uzlu v paměti alokované pole dětí a potomků (a sourozenců), | ||
+ | * Na druhou stranu v některých implementacích bude potřeba při každém zavolání '' | ||
+ | |||
+ | ===== Mají children/ | ||
+ | * Tohle je trochu Python-specific. Pokud by to bylo předpočítané, | ||
+ | * Jenže asi budeme chtít přidávat parametry, a to u properties nejde. Takže z hlediska API jsem pro metody: '' | ||
+ | |||
+ | ===== Mají children/ | ||
+ | * Současné řešení vrací uzly v nedefinovaném pořadí (u descendant průchodem do hloubky, děti pak v pořadí vložení), takže když chci pořadí dle (povrchového) slovosledu, musím zavolat '' |