Consolidate method/function names

[grobie]

The current naming is not stringent nor idiomatic.

From @mdlayher

My personal rules of thumb for each case:

• NewThing: top level constructor functions. Never methods.
• ParseThing: parses some input data like []byte or io.Reader.
• Thing: retrieval methods for some data. Doesn't make much sense as a name for top-level functions to me.

It might make sense to just use the procfs names wherever possible.

[mdlayher]

I'd also like to suggest that we get rid of constructor functions like NewBuddyInfo in favor of methods like: FS.BuddyInfo, because:

• it will shrink the API surface
• it will reduce redundancy
• it will enable much easier testing

[grobie]

@mdlayher You mean all package level shorthand methods? Even Self()?

[mdlayher]

Good question. I suppose it depends how much some of them are used. While they may be convenient, I imagine that most applications will want to construct a FS instance anyway for testing that doesn't only work on Linux machines.

[pgier]

Is this something that we still want to do? After the refactoring in #149, we still have a lot of method names that look like fs.NewSomething(). Using the BuddyInfo example, we have NewBuddyInfo() and fs.NewBuddyInfo(). We could change the fs method to fs.BuddyInfo() however the top level function, can't be changed to just BuddyInfo() because then it conflicts with the BuddyInfo struct. Maybe we can change top level functions to something like ReadBuddyInfo() instead?

[discordianfish]

I think the idiomatic way would be to call it BuddyInfo() and rename the struct instead..

[discordianfish]

See the linked PRs. I think fs.BuddyInfo() is the way to go and I tend to say we should call the package level functions that do the same should also be called the same but that's somewhat against prefixing "top level constructor functions" with New.. @mdlayher Would love your 2 cents on this.

[mdlayher]

I still agree with my previous comment: #44 (comment)

I'd like to see very few package level functions, and everything is only accessible via a method on the FS type.

[pgier]

I agree that it seems better to remove the top level constructor functions and just always require fs to make the API more consistent. So once the current set of PRs are merged, I'll create another PR to:

1. remove the top level NewThing() constructor functions
2. change the FS methods from NewThing() to Thing()
3. since FS would now be required in most/all cases, maybe add a new FS constructor such as NewDefaultFS() for when /proc and /sys are in the default locations.

[discordianfish]

Don't have a opinion on that, so if you think that's better - let's do it.

[pgier]

Fixed in PR #162