You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 4, 2021. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: