search

uber-go / fx

A dependency injection based application framework for Go.
https://uber-go.github.io/fx/
MIT License
5.68k stars 287 forks source link

Discuss: renaming fx.Inject to fx.Extract #572

Closed HelloGrayson closed 7 years ago

HelloGrayson commented 7 years ago

In thinking through how we're going to teach users about breaking glass, I've started to be convinced that fx.Inject should be renamed to fx.Extract.

I find fx.Inject problematic because every dependency in Fx gets injected, not just those passed via types to the inject option. From our and the end users' view, they are performing a non-ideal but very realistic "extraction" from the container. The unique part is not the "inject" aspect, that's perhaps the most common part of Fx- the unique part is extracting the deps directly into a struct in main.

I feel medium/strong about this.

glibsm commented 7 years ago

Hm, interesting idea.

https://github.com/uber-go/dig/pull/118#pullrequestreview-47288601. Not trying to be a jerk, just getting some flashbacks :)

You're right that in the dig's mental model dependency injection typically refers to the constructor injection, yet we also allow to populate fields through similarly named concept of fx.Inject.

I think the main con to renaming could be other libraries' usage of the term inject and what it means. It often means the latter approach: literally filling out the public members of a struct that exist in the graph.

Could you provide some sample sentences, paragraphs, or godocs that would be improved if we switch fx.Inject to fx.Extract?

HelloGrayson commented 7 years ago

@glibsm kicked up a PR with some sample writing that attempts to articulate my thoughts.

I'm pretty convinced that this is low cost and high value, so if you don't feel strongly in keeping it named fx.Inject, then I would consider that I'm even more convinced now that I wrote that PR.