tim.plunkett’s picture

webchick’s picture

Yeah, is there anything to actually discuss here? This was already covered in #1937600: Determine what services to register in the new Drupal class IMO.

Berdir’s picture

I see, so Views started doing it already.

I guess that answers the if but we still have to do it then for other modules and decide which modules should get one :) And how it exactly should work because there was a lot of discussion about that in the original issue (#1875086: Improve DX of drupal_container()->get()), @msonnabaum was suggesting special namespaces/prefix to shorten the namespace. I do disagree with that suggestion, as said there, but it might still need some discussions :) This wasn't discussed or done in the issue from #2.

Also, there are a few cases where will run into some class name issues. For example, user.module is tricky because that already has a User class, so adding another one could make it quite weird as you have to use "use Drupal\user\User as UserService" or something like that as that if you want to use both in the same file. That example would get fixed by switching to UserInterface for the entity type hints, not sure if there are others.

yched’s picture

So, we have a specific use case at #1950088: Move FieldInfo class to the DIC.

FieldInfo class is the broker for the data handed out by field_info_field(), field_info_instances()... We want to put it as a DIC service, and (in followups) eventually get rid of the wrapper field_info_*() functions to have client code call its metods directly.
So, yeah, something like Field::fieldInfo().

As noted by Berdir, though, this pattern of having a helper class named after the module will lead to a lot of name clashes, since the convention in core is to name modules with the singular name of the main "thing" handled by the module - often in D8, that's the name of an entity type (config or content). And thus, the class name is already used for something else.

Views, being the only module that leverages this pattern right now (Views::someService()), happens to also be the only module that breaks this convention by being named views.module instead of view.module :-p. So, works fine there, but not anywhere else.

Class name clashes are not critical since we have namespaces, sure, but unlike the case of name clashes between two classes in two completely unrelated libraries, in in this case both classes will very often get used by the same code, forcing a lot of "use' aliasing in a lot of places (and on a lot of classes once this pattern becomes widely applied).

So, right. Maybe that's not the best solution :-)

andypost’s picture

As #2089807: Rename Field::fieldInfo() to FieldService::fieldInfo() for better DX shows we have 4 Field classes in core now, so it's really confising

yched’s picture

From @David_Rothstein in #2089807-15: Rename Field::fieldInfo() to FieldService::fieldInfo() for better DX:

Another option might be FieldModule::fieldInfo()? I think it's more descriptive, and wouldn't be inconsistent with \Drupal since Drupal is not a module...

why not - works in the sense its less inconsistent with \Drupal. It remains quite obscure as to what the class is useful for, but I guess that's also true of \Drupal, so...

yched’s picture

Priority: Normal » Major

Posponed #2089807: Rename Field::fieldInfo() to FieldService::fieldInfo() for better DX on a naming policy being agreed here. This will apply to all core and contrib modules.

yched’s picture

Title: Decide if and how the module-specific services are made available as static methods(similar to \Drupal::$service()) » [Policy, no patch] Decide how the module-specific services are made available as static methods (similar to \Drupal::$service())
andypost’s picture

From DX pov I see that a lot of contrib modules will provide a classes (entities, services, managers) that would be named as module
For example Flag - entity, plugin and helper service will get the same troubles that Field have now.

View and Views introduces other pattern - make a plural module name so this example is weird

Crell’s picture

I will simply reiterate the position that this practice should be discouraged in general, and modules SHOULD NOT (capitalized in accordance with the RFC) be creating utility classes willy nilly. So "how do module specific services get made available as static methods" is answered with "you don't, because that's a bad idea in the first place."

yched’s picture

I don't think that is realistic. We're trying to move away from field_info_field[s](), field_info_instance[s]() wrappers in favor of direct calls to FieldInfo methods. I don't see us saying "deprecated, use \Drupal::get('')->getField()".
This was deemed no good DX for important Core services, hence the various \Drupal accessors, I don't see why the argument wouldn't hold for services provided by modules (core or contrib) ?

Crell’s picture

yched: "deprecated, inject the field information service instead".

If I'm in a class, I should *never* have to see/use a static method to get at that sort of information. The only static calls I should have to write are to the Utility component.

yched’s picture

@Crell: sure, "if I'm a class".
The cases where "I'm not a class" have been deemed important enough that Core services have static shorthands in the Drupal class. Why wouldn't the same reasoning hold for services provided by modules ?

andypost’s picture

otoh in comment-field we introduce a CommentManager service with some static and other helper methods so before the patch lands we need agreement to use this (some code are proper services but some still procedural - hook_some_alter) also in entity classes and storage controllers we use \Drupal::get('comment.manager') all over core

btw better to have agreement about how to replace this static calls to Drupal::service() that already in core

dawehner’s picture

Yes, you should try to use dependency injection in as many places as possible but there are just places were it won't be possible

  • Potentially on (Static) methods on entities
  • In actual hooks or normal alter hooks


I totally agree that both the DX from both the initial writer as well as from the maintainability perspective is quite bad.
Here I do more care about custom/contrib code than core to be honest.

Given that I think it would make sense for common used services to provide such helper methods.

chx’s picture

dawehner’s picture

Issue summary: View changes

Given how few modules provides such a pattern I don't think this issue is still important. Let's just always use proper DI and be done.

Crell’s picture

Status: Active » Fixed

Agreed with #17. The answer here is "don't, use DI and be done."

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.