mleku on Nostr: it looks ok to me on a brief browse of the codebase... i have written tree walkers ...
it looks ok to me on a brief browse of the codebase... i have written tree walkers before but not full graphs, graphs are more complicated because of the loops
i'd need you to specify the packages and types and functions that you want me to review specifically, i mean, it all looks fairly routine worker loops with channel listener, context done and so forth
the documentation comments should not have () after the function/method name, but you can use an article (a, an, the) in front if appropriate to make a more concise or natural sentence.
also the Database interface is huge, i think it should be broken into several smaller specific interfaces, very often they come as pairs but can be several associated methods that interface with a specific type aspect of the data, you probably know of io.Writer and io.ReadWriterCloser and such, these are composited so you define one interface and then you embed (just put the interface name instead of a method) and it pulls those methods into the interface set
one of the biggest errors that you see in a lot of people's especially early code is mixing what should be two things into one, creating a tight coupling between things that should not be tied together, it makes refactoring and bugfixing harder
anyhow, as i said, i've not written full graph structures before... but a general rule with Go is to avoid recursion unless you know it won't go deep, it has no optimization for recursion, best to stick with iterators instead, but i think that's how you wrote it looking at the Walk stuff - i might only say that it can offen be convenient to write these so they pass a function that lets you put the work nearby the type definitions they relate to, and can also be a neat way to enable you to fan out to multiple threads without having to concern yourself with the concurrency on the "outside" of the type (like how http and filepath libraries let you define handlers, one for responding to requests, the other for doing tree walks)
i'd need you to specify the packages and types and functions that you want me to review specifically, i mean, it all looks fairly routine worker loops with channel listener, context done and so forth
the documentation comments should not have () after the function/method name, but you can use an article (a, an, the) in front if appropriate to make a more concise or natural sentence.
also the Database interface is huge, i think it should be broken into several smaller specific interfaces, very often they come as pairs but can be several associated methods that interface with a specific type aspect of the data, you probably know of io.Writer and io.ReadWriterCloser and such, these are composited so you define one interface and then you embed (just put the interface name instead of a method) and it pulls those methods into the interface set
one of the biggest errors that you see in a lot of people's especially early code is mixing what should be two things into one, creating a tight coupling between things that should not be tied together, it makes refactoring and bugfixing harder
anyhow, as i said, i've not written full graph structures before... but a general rule with Go is to avoid recursion unless you know it won't go deep, it has no optimization for recursion, best to stick with iterators instead, but i think that's how you wrote it looking at the Walk stuff - i might only say that it can offen be convenient to write these so they pass a function that lets you put the work nearby the type definitions they relate to, and can also be a neat way to enable you to fan out to multiple threads without having to concern yourself with the concurrency on the "outside" of the type (like how http and filepath libraries let you define handlers, one for responding to requests, the other for doing tree walks)