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
|
2019-07-24 07:17:40 +00:00
|
|
|
// "source". These sources could be the OS environment, a .gitconfig, or even
|
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
|
|
|
// just a `map`.
|
|
|
|
|
type Fetcher interface {
|
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.
|
2017-04-12 21:29:11 +00:00
|
|
|
//
|
|
|
|
|
// If multiple entries match the given key, the first one will be
|
|
|
|
|
// returned.
|
2016-08-05 21:59:57 +00:00
|
|
|
Get(key string) (val string, ok bool)
|
2016-11-10 00:33:43 +00:00
|
|
|
|
2017-04-12 21:29:11 +00:00
|
|
|
// GetAll returns the a set of string values associated with a given
|
|
|
|
|
// key. If no entries matched the given key, an empty slice will be
|
|
|
|
|
// returned instead.
|
|
|
|
|
GetAll(key string) (vals []string)
|
|
|
|
|
|
|
|
|
|
// 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
|
|
|
}
|
