more consistent function naming style

[eminence]

There are some naming inconsistencies that have been bothering me for a while, and I'd like to solicit input for anyone who has some. There is a mix of free functions that return structures, and constructor methods on structs. Some examples:

• There's a free function process::all_processes() -> ProcResult<Vec<Process>> to get all processes, but a method Process::new(pid) -> ProcResult<Process> to get a single process
• There's a free function cpuinfo() -> ProcResult<CpuInfo> to get CPU Info, but when getting memory info, you use a constructor method Meminfo::new() -> ProcResult<MemInfo>

My personal inclination is to remove the number of free functions (except when necessary, because there's no struct to attach to. boot_time_secs() -> ProcResult<u64> is a good example of this), but I'm curious to know if anyone else has any thoughts on this

[idanski]

Sounds good! Thanks!!

My two cents: cpuinfo() vs Meminfo::new() seems more inconsistent then process::all_processes() (You could argue that since there is no ProcessList struct it is a valid free function).

[cjbassi]

I maintain rust-psutil which follows the psutil API and we actually mostly just use free functions, the one exception being Process::new. One instance where this feels right is that we have some functions like cpu_times() which returns a CpuTimes and cpu_times_percpu which returns a Vec<CpuTimes>. I'm not really sure if there's a right answer to this one though, but the important part seems to probably be to have consistency across the project.