Provide a way to control the visibility of imported methods

[chocolateboy]

I love DRYing up wiring with this module (I'm not currently using it for testing/mocking). It's a great way to make dependencies between components declarative, rather than imperative. 🍒

But (perhaps because I'm not using it for testing), I don't want those methods to be public. In fact, I've always wanted them to be private so far. In addition, I don't want to contaminate my interfaces with the inject! method, which I don't anticipate using (though, again, I can see how it could be useful for tests).

Any chance the API could support private and protected imports in addition to the current public imports? e.g.:

before

include DI.inject :foo, :bar

# is equivalent to

public def foo
public def bar

after

include DI.inject private: :foo, protected: %i[bar baz], public: :quux

# is equivalent to

private def foo
protected def bar
protected def baz
public def quux

It could easily remain backwards compatible with the current usage, if that's an issue i.e. use the hash(es) for access control and default the rest to public e.g.:

include DI.inject :foo, private: :bar: protected: :baz, public: :quux

# is equivalent to

public def foo
private def bar
protected def baz
public def quux

As for inject!, it could either be imported explicitly (which would allow its visibility to be controlled) e.g.:

include DI.inject :foo, private: %i[bar inject!]

# is equivalent to

public def foo
private def bar
private def inject!

Or, if there's a common need for it to be injected automatically, a dedicated method could be used instead e.g.:

include DI.inject! :foo, private: :bar

# is equivalent to

public def foo
private def bar
public def inject!

[jhollinger]

I like this in principle, esp. if it's backwards compatible. Would certainly prevent people from "abusing" services that are meant to be black boxes. I'd be happy to accept a PR if you want to give it a shot. Otherwise I might take a crack at it in a few weeks.