rob05c edited a comment on issue #2886: TO Golang: Small CRUDer change to allow 
interface use for a single method type
URL: https://github.com/apache/trafficcontrol/pull/2886#issuecomment-427107525
 
 
   >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.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


With regards,
Apache Git Services

Reply via email to