git-lfs/config/fetcher.go

package config

// Fetcher provides an interface to get typed information out of a configuration
// "source". These sources could be the OS enviornment, a .gitconfig, or even
// just a `map`.
type Fetcher interface {
	// Get returns the string value associated with a given key and a bool
	// determining if the key exists.
	Get(key string) (val string, ok bool)

	// All returns a copy of all the key/value pairs for the current environment.
	All() map[string]string
}
config: introduce Fetcher type As per my comments in https://github.com/github/git-lfs/pull/1390#issuecomment-236068550, I'd like the `config.Config` type to be focused solely on data fetching, not having to know about the domain of each of its callers. The `Fetcher` type is the first step in that direction. `Fetcher` is an interface designed to be implemented in three ways, concrete types that wrap: 1) Interaction with the `.gitconfig`. 2) Calls to `os.Getenv`. 3) A `map[string]string` for testing. In this initial implementation, the `Fetcher` is responsible for type conversion, providing methods like `Fetcher.Bool` and (eventually) `Fetcher.Int`. The above is undesirable for a number of reasons: 1) It forces implementers of the `Fetcher` type to be responsible not only for data-fetching, but also data conversion. 2) At the time of writing, data conversion is uniform throughout the LFS codebase. This encourages code smells by way of duplication in that all types will have to implement the same sort of type conversions with the same sort of code. The alternative is to have static helper methods, or weird abstraction trees, but this is similarly undesirable. In subsequent PRs, I plan to demote the Fetcher type to a function: ``` type FetchFn func(key string) (val string) ``` and introduce an `Environment` type which has* a `FetchFn`. In doing so, I'll delegate the responsibility of implementing the `Bool` and `Int` (etc) methods to the concrete `Enviornment` type, and only implement it once. 2016-08-03 22:06:25 +00:00			`package config`

			`// Fetcher provides an interface to get typed information out of a configuration`
			`// "source". These sources could be the OS enviornment, a .gitconfig, or even`
			// just a `map`.
			`type Fetcher interface {`
change (Environment) Get()'s signature to include ok bool 2016-08-05 21:59:57 +00:00			`// Get returns the string value associated with a given key and a bool`
			`// determining if the key exists.`
			`Get(key string) (val string, ok bool)`
remove AllGitConfig() 2016-11-10 00:33:43 +00:00
add export comments 2016-11-10 18:24:45 +00:00			`// All returns a copy of all the key/value pairs for the current environment.`
remove AllGitConfig() 2016-11-10 00:33:43 +00:00			`All() map[string]string`
config: introduce Fetcher type As per my comments in https://github.com/github/git-lfs/pull/1390#issuecomment-236068550, I'd like the `config.Config` type to be focused solely on data fetching, not having to know about the domain of each of its callers. The `Fetcher` type is the first step in that direction. `Fetcher` is an interface designed to be implemented in three ways, concrete types that wrap: 1) Interaction with the `.gitconfig`. 2) Calls to `os.Getenv`. 3) A `map[string]string` for testing. In this initial implementation, the `Fetcher` is responsible for type conversion, providing methods like `Fetcher.Bool` and (eventually) `Fetcher.Int`. The above is undesirable for a number of reasons: 1) It forces implementers of the `Fetcher` type to be responsible not only for data-fetching, but also data conversion. 2) At the time of writing, data conversion is uniform throughout the LFS codebase. This encourages code smells by way of duplication in that all types will have to implement the same sort of type conversions with the same sort of code. The alternative is to have static helper methods, or weird abstraction trees, but this is similarly undesirable. In subsequent PRs, I plan to demote the Fetcher type to a function: ``` type FetchFn func(key string) (val string) ``` and introduce an `Environment` type which has* a `FetchFn`. In doing so, I'll delegate the responsibility of implementing the `Bool` and `Int` (etc) methods to the concrete `Enviornment` type, and only implement it once. 2016-08-03 22:06:25 +00:00			`}`