Can we accommodate trees defined in a "bottom-up" way? (nodes pointing to parents)

[LeaVerou]

I recently came across some use cases of trees where familial relationships were defined in the inverse way of what we assume: instead of nodes pointing to their children and assuming the parents can be derived, the nodes were pointing to their parents, and the children could be derived. I cannot remember what they were, but will update this comment when I do.

How could we accommodate such use cases?

At the very least, we should be able to accommodate use cases where the parent is part of the data, and does not need to be hidden away in a weakmap.

[LeaVerou]

Just realized an example of such a case, though a little far-fetched: OOP superclasses and subclasses.

Each class has a reference to its parent (super) but not to its child classes. However, referencing the children is pretty frequently needed. Consider the common pattern where we have a static factory method on the base class that gives us an instance of a suitable subclass. This means the base class needs to keep track of subclasses (children) manually.

I’ve personally had to deal with this many times:

• In Mavo and Madata’s Backend classes
• In Mavo’s Node class
• In Madata’s Format class
• In Color.js’s ColorSpace class

Typically, subclasses have to "register" themselves by calling something like BaseClass.register(SubClass) and then maintain a data structure of subclasses.

[LeaVerou]

Another example of bottom-up trees is Color.js color spaces: Each color space object has a base property that points to another color space (with the exception of a few basic ones) but there are no pointers to the color spaces that use a given color space as their base.

This produces a tree that looks like this (though it would be a lot more complex today): https://colorjs.io/docs/spaces