Add a @PluginID annotation for plugins that only need an ID, like Views handlers

One problem I do have with this is the fact, that a random developer can no longer apply exactly what he has learned so far on plugins,
and write @Plugin etc. Does this mean that each plugin type has it's own class here?

What would happen if they actually want to add additional metadata. For example :

 * @Plugin(
 *   id = "date_fulldate",
 *   arg_format = "Ymd",
 *   format = "F j, Y",
 *   module = "views"
 * )

Would you need to specify a new annotation class, or use @Plugin() again?

If we think this is a good idea I think we should name it ViewsPlugin() because the main reason why people get confused about handlers in the firstplace is that we call them different. If people understand the plugins concept, having another name feels really counterproductive.

Handlers are pretty straightforward, and actually don't need anything other than their ID.

Handlers are plugins, that's it. Noone should stop you from using additional metadata, if you think it's a good idea.

Views is the owner of the API, and as the consumer should define up front what metadata is appropriate for each plugin type. Any of that information is not metadata, and is only useful with an instantiated object.

Good point, so I will open a follow up to get this cleaned up now.

And there is still an important distinction between a handler and a plugin (in the views sense), even the base class points this out.

Please let avoid that different naming in the first place. A dev don't need the name "handler" to know. Filter is just another plugin type provided by views.

I guess with moving to yml files we don't need this anyway.

  /**
   * The plugin ID.
   *
   * @var string
   */
  public $value;

we definitely need no stinkin' comments on why do we store the ID in $value. No.

@tim, I was going to ask about the module key. What issue was that?

+++ b/core/modules/user/lib/Drupal/user/Plugin/views/filter/Roles.phpundefined
@@ -15,10 +15,7 @@
- * @Plugin(
- *   id = "user_roles",
- *   module = "user"
- * )
+ * @PluginID("user_roles")

I'm wondering whether we should still have the module information somewhere stored. I guess some layer could add them in later.

+++ b/core/modules/views/lib/Drupal/views/Plugin/Discovery/ViewsHandlerDiscovery.phpundefined
@@ -0,0 +1,58 @@
+    $annotation_namespaces = array(
+      'Drupal\views\Annotation' => DRUPAL_ROOT . '/core/modules/views/lib',
+    );

Now that we have the @PluginID one, can't we now inherit from the Core/ one?, as we don't need the constructor anymore? I don't see an advantage to not reuse the other one.

+++ b/core/modules/views/lib/Drupal/views/Plugin/Discovery/ViewsHandlerDiscovery.phpundefined
@@ -0,0 +1,58 @@
+    array_walk($definitions, function (&$definition, $key, $type) {
...
+    }, $this->type);

Can't we just use function (&$definition, $key) use ($type)?

+++ b/core/modules/views/lib/Drupal/views/Plugin/Discovery/ViewsHandlerDiscovery.phpundefined
@@ -0,0 +1,58 @@
+      $definition['plugin_type'] = $type;

Can't we still add this as default value on the manager?

+++ b/core/modules/views/lib/Drupal/views/Plugin/ViewsHandlerManager.phpundefined
@@ -0,0 +1,35 @@
+    $this->discovery = new ViewsHandlerDiscovery($type, $namespaces);
+    $this->discovery = new CacheDecorator($this->discovery, "views:$type", 'views_info');
+
+    $this->factory = new DefaultFactory($this->discovery);

I think, that we can't know whether someone wants to use the alter decorator, etc., which then at the end of the day would all fallback to use just the ViewsPluginManager as it is.

See also: #1825896: Add module owner to plugin data on handlers

Nice. I still like the idea of us storing the plugin module.

I like @PluginID ok. A single annotation is nicer than a hash when possible.

Patch looks pretty good, although I think the array_walk is not necessary. It's less readable than foreach in this context since you have to pass around the reference.

One thing I wanted to address:

One problem I do have with this is the fact, that a random developer can no longer apply exactly what he has learned so far on plugins,
and write @Plugin etc. Does this mean that each plugin type has it's own class here?

For me, this is the goal. Developers should know that Entity types require an annotation and Views handlers require an annotation, but it's not necessary to know that they are using the Plugin system. Plugins are very difficult to understand in the abstract, so I think the best possible DX we can offer is to treat them like an implementation detail.

Looks fine, let's wait for arguments.

If thinks this is RTBC beside this small nitpick.

+++ b/core/modules/views/lib/Drupal/views/Plugin/Discovery/ViewsHandlerDiscovery.phpundefined
@@ -0,0 +1,58 @@
+   *   (optional) Array of root paths keyed by the corresponding namespace to
+   *   look for plugin implementations, \Plugin\views\$type will be appended to
+   *   each namespace.

Defaults to array()

Awesome!

Committed ee1c53e and pushed to 8.x. Thanks!

YAY!

Please update issue summary or file change notice to how to use it now!

Yeah, this actually needs both a core change notice (for the core API addition) and a views one. (The views one being added on top of the major views plugin conversion one we haven't written yet.) ;)