Namespaces are currently not first-class MDS objects. They cannot be the value of record fields or array slots, so you're limited to searching for them by (hierarchical) name from the root namespace.
To most easily handle the sort of cross-context data structures (like history lists), it would be useful if we could just have a list of namespaces in detached snapshots. This would allow the data stored in them to be flexible (and not necessarily consistent across elements) and would allow for computations to memoize their results.
Aside from turning namespace handles into view-relative handles, this would require creating a (single) namespace type object.
One difficulty: Given the current namespace implementation, it's not at all clear how to do namespace assignment into a namespace. That is,
is difficult, because if "name" was already used as a namespace in an earlier lookup (say, to look up "name/count", there would already be a namespace there. So we may initially want to forbid explicit bindings of namespaces to names and require that namespaces be obtained by lookup or, perhaps, by creating them free-floating.
Most of this is straightforward--a matter of adding a namespace type, namespace field, namespace arrays, etc. Pretty much everything that ManagedRecord has. But it also means that it needs to be patched into the annotation processor to recognize Namespaces as the sort of things that can be use as field types, and that's more than I have time to do right now.
[imported from HPE issue 300]
Namespaces are currently not first-class MDS objects. They cannot be the value of record fields or array slots, so you're limited to searching for them by (hierarchical) name from the root namespace.
To most easily handle the sort of cross-context data structures (like history lists), it would be useful if we could just have a list of namespaces in detached snapshots. This would allow the data stored in them to be flexible (and not necessarily consistent across elements) and would allow for computations to memoize their results.
Aside from turning namespace handles into view-relative handles, this would require creating a (single) namespace type object.
One difficulty: Given the current namespace implementation, it's not at all clear how to do namespace assignment into a namespace. That is,
is difficult, because if
"name"was already used as a namespace in an earlier lookup (say, to look up"name/count", there would already be a namespace there. So we may initially want to forbid explicit bindings of namespaces to names and require that namespaces be obtained by lookup or, perhaps, by creating them free-floating.Most of this is straightforward--a matter of adding a namespace type, namespace field, namespace arrays, etc. Pretty much everything that ManagedRecord has. But it also means that it needs to be patched into the annotation processor to recognize Namespaces as the sort of things that can be use as field types, and that's more than I have time to do right now.