Over in, we had a lively discussion about the DX impact of things like this:
and changed them to things like this:
However, in the later comments (from about #144 on) had some contentions around this part of the proposal:
"And for a service that is obscure, rarely used, or not intended to be used as a public API:"
+ Drupal::service('some.service.')->someMethod(); // Either this or the previous line, not both.
Suggestions (and concerns) can basically be summarized as:
- Decide on a case-by-case basis (How? What criteria? How will this be easily communicated to "end developers" so they know what to expect?)
- Apply a standard rule that just chucks everything in /includes or /Drupal/Core into a method on the class (It can't be this simple though; there are hundreds of things registered as services and we need a way to differentiate a "major" service from a "minor" one that's never intended to be used as a public-facing API)
All public API's get a method on the Drupal class. The initial patch in this issue adds a bunch of those and also converts some existing calls to those new methods. The idea is to a) minimize conflicts between the follow-up conversions and provide some examples, so that the follow-ups can be done as Novice issues. It does not mean to be a complete list, additional methods can be added any time later.
(Fill follow-up issues as necessary and update change notice(s) according to the following lists)
Added as a method and already converted as an example (can be considered done)
Added as a method but not yet converted/removed the old function (Needs follow-up issue per method if not yet existing to convert existing calls for the eventually existing old function/drupal_container() and removal of the eventually existing function)
Not (yet) added (Needs an issue to discuss/add if not yet existing)
* url generator (
* request (Requested to be left out by @Crell, @msonnabaum disagreed (I think?) in IRC, let's fight! in )
* plugin managers ( )
I'm not adding any services that are not supposed to be called directly/manually (like event listeners, compiler passes, route access checks, ...). Also haven't added module specific services yet. We have not yet discussed what to do with that after the initial discussion in the original issue.
Once those specific cases are done,can be unpostponed to get rid of the remaining calls, which should only be a few remaining ones. And we can always add more methods if we find more useful ones later on.
See remaining tasks.
|PASSED: [[SimpleTest]]: [MySQL] 53,866 pass(es).|
|PASSED: [[SimpleTest]]: [MySQL] 54,055 pass(es).|
|PASSED: [[SimpleTest]]: [MySQL] 53,385 pass(es).|
|FAILED: [[SimpleTest]]: [MySQL] 53,295 pass(es), 12 fail(s), and 0 exception(s).|