there's a shitton of code duplication with the existing adjacency lists. a lot of that could be done away with (along with the shitty pseudoinheritance) by replacing the guts of the logic with some unexported functions with type switches.
while this would shift the internal logic out of a single place for a struct, it would centralize the deviations for any given operation into a single place - an overall complexity reduction, methinks. plus, organizing a struct in one file is kind of an artificial thing in go, anyway.
done a fair bit of this, but it's increasingly seeming like it's better to reduce the N factor is by reducing the complexity in other areas. closing this for now, may reopen later.
there's a shitton of code duplication with the existing adjacency lists. a lot of that could be done away with (along with the shitty pseudoinheritance) by replacing the guts of the logic with some unexported functions with type switches.
while this would shift the internal logic out of a single place for a struct, it would centralize the deviations for any given operation into a single place - an overall complexity reduction, methinks. plus, organizing a struct in one file is kind of an artificial thing in go, anyway.