Quantcast
Viewing all articles
Browse latest Browse all 292476

Determine what services to register in the new Drupal class

Postponed on #1875086: Improve DX of drupal_container()->get().

Over there, we had a lively discussion about the DX impact of things like this:

drupal_container()->get('flood')->register($event_name);

and changed them to things like this:

Drupal::flood()->register($event_name);

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_container()->get('some.service')->someMethod();
+ Drupal::container()->get('some.service')->someMethod();
+ 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)


Viewing all articles
Browse latest Browse all 292476

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>