[Policy, no patch] Decide how the module-specific services are made available as static methods (similar to \Drupal::$service())

See http://drupalcode.org/project/drupal.git/blob/refs/heads/8.x:/core/modul...

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.

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 :-)

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

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...

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.

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

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."

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('field.info')->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) ?

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.

@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 ?

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

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

\Drupal::get('comment.manager')

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.

#2084637: Use a service container with automated wrappers

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.

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