Use object destructuring for dependency injection about open-api

[jsdevel]

Very coincidental that you've opened this. Over the weekend I published difunc. It uses esprima which handles arrow functions (the current solution does not).

While object destructuring works great for shortening code, it doesn't validate that the dependency you're wanting to use is actually defined.

[bugeats]

Very coincidental that you've opened this. Over the weekend I published difunc. It uses esprima which handles arrow functions (the current solution does not).

... and the entire babel runtime apparently. You'll probably find yourself updating regexes with every new JS runtime that comes out.

While object destructuring works great for shortening code, it doesn't validate that the dependency you're wanting to use is actually defined.

I don't find this to be a problem, and at a higher level I believe it to be fighting the nature of JS. Module tests are good enough for me.

---

Hmm... given that you just authored a project just for introspective dependency injection, I don't think we're ever going to agree on this topic. I wish you well, but at this point it's clear to me that I need to go in a different direction.

BTW, I was attracted to the word "unopinionated" when picking an openapi framework last week. IMHO, dep injection magic and forced directory layouts are not unopinionated. Might just want to embrace the opposite terminology.

[jsdevel]

I don't think we're ever going to agree on this topic. I wish you well, but at this point it's clear to me that I need to go in a different direction.

There are less abrasive means of engaging in dialog on github for an open source project that a maintainer is voluntarily donating their time to. I'm not opposed to any of your ideas. I appreciate you for raising your concerns. My goal is to make the framework better for everyone.

BTW, I was attracted to the word "unopinionated" when picking an openapi framework last week. IMHO, dep injection magic and forced directory layouts are not unopinionated. Might just want to embrace the opposite terminology.

1. I'm not opposed to object destructuring. I just hadn't considered it as an option. And just because I published a package (difunc), doesn't mean I'm 100% sold on using it.
2. I agree that babel-runtime is a non-starter. I'll remove that from difunc so it's not required.
3. For me the danger in destructuring is the potential to unknowingly break your API by removing a dependency in .initialize. Up until now, users of express-openapi who've used the DI feature have had some level of confidence knowing that the framework has their back in terms of ensuring that the dependency is defined. With object destructuring there's no way to provide that guarantee. Stability is a priority for this framework.
4. There's nothing forcing people to use DI. Going with object destructuring is just as opinionated as supporting angular style DI. There's also nothing stopping you from defining api documentation in the global api doc. This was added recently. I'm also open to PRs that provide support for wiring up the handlers through operation name or some other means.

[jsdevel]

See #96