New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Begin systemizing files in pkg/registry #730
Conversation
Files that have RESTStorage implementations now end in "storage", and files that have registries now end in "registry". I removed some underscores in file names, since it seems to be go style not to have them. I split minion_registry.go into two files. We should consider splitting this package into two, to make more clear the separation between the layers.
type ServiceRegistryStorage struct { | ||
registry ServiceRegistry | ||
cloud cloudprovider.Interface | ||
machines MinionRegistry | ||
} | ||
|
||
// MakeServiceRegistryStorage makes a new ServiceRegistryStorage. | ||
func MakeServiceRegistryStorage(registry ServiceRegistry, cloud cloudprovider.Interface, machines MinionRegistry) apiserver.RESTStorage { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a Go convention for New vs Make? I wasn't aware of Make being that common in the stdlib.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there is a convention, and it is New. Make is reserved for maps and channels, everything else is new, and every package with a constructor that I'm aware of also uses New. We should change this. Not in this PR though.
As a follow on (here, or in a later change), it might be worth it to move each of the resources to their own package (storage and registry impls). Not much benefit to them being collocated. Ie |
LGTM besides incidental comments |
I agree with that follow up. |
Begin systemizing files in pkg/registry
is it really go style to have runtogetherfilenames that nobody can read ? Can we please pretty please buck that trend? On Fri, Aug 1, 2014 at 7:57 AM, Clayton Coleman notifications@github.com
|
I think the idea is that if you need multiple words, it's a clue that it's time to split your package. Indeed, this package should be split... I couldn't bring myself to stick more than two words together. :) I actually don't care much about the underscores, the thing that was bothering me were the inaccurate suffixes (registry instead of storage). |
I am fine with somewhat terse names, but the idea that every file can be a I think we already suffer from the latter.
|
Add support for parsing CPU speed from /proc/cpuinfo on Power (ppc64) systems
Files that have RESTStorage implementations now end in "storage", and
files that have registries now end in "registry". I removed some
underscores in file names, since it seems to be go style not to have
them. I split minion_registry.go into two files.
We should consider splitting this package into two, to make more clear
the separation between the layers.
I added two comments but otherwise did not change any code.