@thinkaboutthebible, On object orientation, I think I see what you’re saying. I hadn’t thought about it in much detail until you wrote about it here.
So, the most popular data structure is the [linked list] ← → [memory palace], with native items stored in each node. We can create a [tree] ← → [hierarchical memory palace] by adding an extra link from each node to another memory palace. With this tweak, we simply enhanced the node object (i.e., it still has fields for the native item stored and the link to the next locus object but now, in addition, it also has a link to the head of a different, sub-hierarchical memory palace). I think what’s important to note is that we did not change the type of the item stored, it’s still native. But maybe there’s something to be gained by changing those storage items from native data types to bespoke object data types?
This was sort of a theme in Historical timeline memory: my proposed system. There, I considered changing the data type of the locus object (which I believe has an analog of memory address in the computing world) from a native data type to a bespoke data type. So, e.g., we might start with each locus object being a piece of playground equipment. But then we could enhance each by considering its north, south, east, west components. We might store political history stuff at the north component, scientific history stuff at the south component, etc. But that’s not exactly the same as changing the data type of the storage object…
But I did speak about enhancing the data type of the storage object from native data type to a DAG, in the case of a historical episode.
So, what I’m understanding: we don’t typically bring in OO machinery because we only have a couple containing data structures and we typically only store native data types in them. But we could benefit from thinking about new containing data structures (which are just objects themselves) and non-native data-types objects for storage.