rytc
commented
10 months ago I originally split it up so that if someone wanted to find all the public peer procedures, then they could open up the file. But on the other hand, everything is prefixed with peer_ or host_ so maybe it's not that big of a deal search-wise. It also keeps the internal procedures for the context close by, so it might make it easier see what's in module scope and what's in public scope when looking at the code because the files are smaller so you don't have to scroll far up and see if this procedure is under a #scope_module.
It is nice to have single file modules though, like when I was bug hunting with the zpl-c code, it's nice to have a single tab and do a search. I would be okay with putting it into one file
okmatija
What do you think of plopping all the code into a single file, enet.jai, so that its a single file module? This would make searching the code easier since you can just Ctrl-f and find everything rather than needing to do some multi-file search thing. Its also nice to have as few tabs as possible related to other peoples code, currently when I work on networking stuff in my game I have a few tabs dedicated to just this module.
A separate point: there are a bunch of comments in the C repo which would be helpful to have here, what do you think about bringing them over? If we did the single file thing in a way which closely mirrors the positioning of functions in the C repository (https://github.com/zpl-c/enet) then even if we didn't port the documentation it would be easy to compare this code with theirs, this was a helpful thing to do when I was debugging the peer_reset function in an earlier PR. My preference would be do the single file thing as well as port the documentation though.
I am open to doing both of the above, I'm just checking how you feel about them before putting the work in :)