Make EntityProvider have optional methods

[cespedes]

I think it would be very nice to modify EntityProvider so that it accepts an empty interface.

HandleEntities could checks in runtime if it implements the desired method (EntityCreater, EntityGettry, EntityUpdater, EntityDeleter or EntityLister), execute it if so and, if it does not implement the interface corresponding to the method used, return a "Not Implemented".

What do you think? It should be easy to implement and quite useful, in my opinion...

[dolanor]

Hi @cespedes

I love the idea of a mix and match method implementation. I actually had this idea in the beginning What I don't like about that idea, is that it says nothing via this interface{}. I really believe the API needs to be well designed not to be wrongfully used.

Not possible with current generics version

I wrongfully believed we could actually use an union between types. We actually can for normal types, but not for interfaces. So I hoped to use it. But it was not possible, and I'm not sure it will be. I really created this project while generics were in preview behind a build flag, so I was experimenting with it.

Possible solution

Default Provider

Create a rip.DefaultProvider that have all the methods returning a rip.ErrNotImplemented that you could embed in your own provider

type FooProvider struct {
    rip.DefaultProvider
}

func (p *FooProvider) Get(ctx context.Context, fooID FooID) (*Foo, error) {
     // whatever you need
}

Pro

• Quite easy to use
• The API stays explicit, in a way

Cons

• Maybe a rip.ErrNotImplemented is not what you want to communicate. We could return a rip.ErrNotFound instead if it's any better.
• your provider depends directly on rip package (where I would like to have no dependency in your provider code). Maybe using type alias, it could be possible to invert the dependency. I need to experiment that in some hexagonal architecture example.

What do you think?