>Looking at the playground again, it seems endpoint writers have two options.
>1) implement either full CRUDer or 2) create a factories for each operation
>individually. Supposing every operation is needed except for the delete (as an
>example), would you expect the implementor to have an extraneous delete
>function, or to create three separate factories?
I don't think that's a common case, and if it is, creating Factories for each
type doesn't seem unreasonable. Each Factory should only be 3 lines,
```
func CreateFactory() api.CreateFactory {
return func(reqInfo *api.APIInfo) api.Creator { return
&TODivision{reqInfo, tc.DivisionNullable{}} }
}
func ReadFactory() api.ReadFactory {
return func(reqInfo *api.APIInfo) api.Reader { return
&TODivision{reqInfo, tc.DivisionNullable{}} }
}
```
In fact, I've wondered if we should just get rid of the `CRUDer` interface, and
require every endpoint to implement its own type. I'm not sure there's really a
reason to keep them together, except saving a few lines of code.
Actually, there's another option too: we could get rid of the factories
altogether, by adding a method to populate the `APIInfo`, `func (v *TODivision)
SetInfo(i *api.APIInfo) { v.ReqInfo = i }`, and changing the "CRUDer" funcs to
take the actual object instead of a factory:
```Go
{1.1, http.MethodGet, `divisions/?(\.json)?$`,
api.ReadHandler(division.TODivision{}), auth.PrivLevelReadOnly, Authenticated,
nil},
```
and then `ReadHandler` calls `v.SetInfo()` on the object it receives.
Now that I think about it, I like that solution. That fixes the fundamental
issue, that Go polymorphism can't perform duck typing on function parameters.
And IMO factories are a pain to deal with anyway.
What do you think about that solution, getting rid of factories altogether?
That provides the flexibility you want, allowing a type to only implement the
CRUD types it uses, while still preserving type safety, and also being a
simpler and more idiomatic solution than factories.
[ Full content available at: https://github.com/apache/trafficcontrol/pull/2886
]
This message was relayed via gitbox.apache.org for devnull@infra.apache.org
