I think it would be great if we could subclass the LayoutPass.
All the generic functionality could be in the parent to run the layout-after/in-group/ and currently the layout-before passes(until it gets removed).
Flavors can choose to run the layout passes that they use and determine the way things get ordered in the layout pass.
The compare function in the LayoutPass would call doLayoutAfter, doInGroup.
Any concerns on sub-classing ?
Existing reference kinds, namly layout-before (until it’s removed), layout-after and in-group, have clear semantics that is already implemented in the layout pass. For example, hen you create a reference from atom A to B with a layout-after reference, B will be always placed after A. Allowing users to redefine such basic relationship is more confusing than good. It’s like redefining an operator, so caution needed.
Do you have any immediate need to subclass it? Because we have the entire codebase, we can add such abstraction when we need it, so doing it beforehand for future possible use tend to be overdesigning stuff.
I think flavors would use only a subset of the reference kinds that are available. There is no need to spin in a reference kind, which doesnot find any atom.
For example, I am not sure if MachO/COFF have weak symbols,the current layout passes are very generic and if the usecase is not relevant, we can curtail those passes in the subclasses as well.
This could simplify and could achieve good speed up too.