while I still keep my stance not to allow reflection and switch-on-type, access to the internal / semantic type of an embedded record seems a valid compromise to allow to deal with collections of object-like children of mixed kind. Indirectly (and quite intentional) this also opens a loophole to detect if a given GenNode might constitute a nested scope, but with the for the actual nested element indeed to cary a type symbol. Effectively this limits the use of this shortcut to situations where the handling context does have some pre-established knowledge about what types *might* be expected. This is precisely the kind of constraint I intend to uphold: I do not want the false notion of "total flexibility", as is conveyed by introspection. |
||
|---|---|---|
| .. | ||
| diff-index-table-test.cpp | ||
| diff-list-application-test.cpp | ||
| diff-list-generation-test.cpp | ||
| diff-tree-application-test.cpp | ||
| diff-virtualised-application-test.cpp | ||
| gen-node-basic-test.cpp | ||
| generic-record-representation-test.cpp | ||
| generic-record-update-test.cpp | ||
| generic-tree-representation-test.cpp | ||
| tree-manipulation-binding-test.cpp | ||
| tree-mutator-test.cpp | ||