support passing receiver method as provider

[zzzz465]

Is your feature request related to a problem? Please describe.

When a Wire provider function is a trivial method delegate — its only purpose is to call a method on one of its parameters and return the result — it adds boilerplate without any value.

func DatabaseProvider(opts *APIServerDatabaseOptions) (*gorm.DB, error) {
  return opts.ToDB()
}

var Set = wire.NewSet(
  DatabaseProvider, // wrapper just to call opts.ToDB()
   // ...
)

Describe the solution you'd like

support below pattern for simpler provider function passing

var Set = wire.NewSet(
  (*APIServerDatabaseOptions).ToDB, // directly use the method
  // ...
)

Describe alternatives you've considered

I think this is the simplest way to solve this problem.

Additional context

I used goforj/wire v1.1.0

[cmilesio]

Do you run into this scenario often?

I would normally just make a provider function myself for an instance like this and have not run into it that often.

[zzzz465]

Do you run into this scenario often?

I would normally just make a provider function myself for an instance like this and have not run into it that often.

My application requires a lot of arguments (10–30+), and many entry points share similary things but different. So, wiring itself has a complexity that need to be receiver methods. for now I write Provider function for each of them but if wire supports receiver method I think I reduce LoC for easier code reading

[zzzz465]

also if generic is supported, it would be nice too. for example, I use generic type Authorized[T] to enforce that some code only can get authorized code, not a raw code. currnetly wire doesn't recognize Type[T] pattern so I need to use each of them.

I could generate each Authorized <T> type using a generator, but, for me, using generics for requirements looks nice. because, using generic supports typing correctly and only throws error in wire step, but if we depend on the type that is generated in logic code, it simply cannot resolve the actual type before generating.

(this should be created to another issue though)

[cmilesio]

also if generic is supported, it would be nice too. for example, I use generic type Authorized[T] to enforce that some code only can get authorized code, not a raw code. currnetly wire doesn't recognize Type[T] pattern so I need to use each of them.

I could generate each Authorized <T> type using a generator, but, for me, using generics for requirements looks nice. because, using generic supports typing correctly and only throws error in wire step, but if we depend on the type that is generated in logic code, it simply cannot resolve the actual type before generating.

(this should be created to another issue though)

I'd say file a separate feature request issue for this and give an example shape of what it is that you're looking to enable and I can take a look at it soon.

[cmilesio]

Do you run into this scenario often?
I would normally just make a provider function myself for an instance like this and have not run into it that often.

My application requires a lot of arguments (10–30+), and many entry points share similary things but different. So, wiring itself has a complexity that need to be receiver methods. for now I write Provider function for each of them but if wire supports receiver method I think I reduce LoC for easier code reading

I'll see if I can take a look at it soon, in the middle of wrapping up #3

[zzzz465]

Do you run into this scenario often?
I would normally just make a provider function myself for an instance like this and have not run into it that often.

My application requires a lot of arguments (10–30+), and many entry points share similary things but different. So, wiring itself has a complexity that need to be receiver methods. for now I write Provider function for each of them but if wire supports receiver method I think I reduce LoC for easier code reading

I'll see if I can take a look at it soon, in the middle of wrapping up #3

@cmilesdev I tried #3
it works fine in local environment. wire time decreased from 20s to 1s. but practically it is not usable in CI because some variables like WIRE_SEMANTIC_CACHE_DIR is hard-coded

[cmilesio]

@zzzz465 give this a whirl when you can #6

[zzzz465]

I tested it and it works fine. nice!

[zzzz465]

@cmilesio reminder ping

[cmilesio]

@cmilesio reminder ping

Thanks! I'll merge it in.

Sorry I've had a lot going on. Thanks for your patience! 🫡