Follow up to #2631202: Doctrine no longer supports SimpleAnnotationReader, incorporate a solution into core to avoid mixing topics.

Since the Doctrine SimpleAnnotationReader, on which our discovery process currently rests, is deprecated, and Doctrine won't keep maintaining to support PHP 5.x version D8 supports, we need a way to

* either replace SimpleAnnotationReader as such (which is the topic of #2631202: Doctrine no longer supports SimpleAnnotationReader, incorporate a solution into core)
* or go one step further replace the annotation-based discovery method itself, possibly by a mechanism not based on annotations at all.

The existing discovery mechanism supports 4 generic base mechanisms: annotations (most used), info hook (traditional, but essentially obsoleted), yaml-based (e.g. new-new menu links system), and static (e.g. constraints manager), plus decorators, and some dedicated (e.g. config schema).

Beyond the issue of depending on code deprecated by the upstream community (Doctrine), annotation-based discovery suffers from multiple issues, which were already discussed at the time it was introduced, but warrant being reconsidered in the light of this deprecation, including:

  • the "philosophical" issue of having code in comments
  • the more concrete issue of having this code-in-comments have very limited expressivity, and essentially providing only array-level structural information, which is a problem it shares with the D7 and earlier info hooks. As a matter of comparison, yaml discovery can be slightly more expressive, including the ability to rely on a schema, and include references, all of which is already used e.g.in configschema
  • a technical issue with annotation parsing which has to be done
    • either at the tokenizer/parser level, treating source code essentially as raw data files, thus having to reimplement part of the logic of the actual PHP interpreter (e.g. namespace handling) on top of the tokenizer
    • or using Reflection, which causes memory issues, and might also cause conflicts in some cases where multiple implementations of the same class in the same namespace can exist and differ only by their loading path (e.g. API versions)
  • the issue of having code at two data realms (code vs annotations), causing repetition and introducing a possibility of inconsistency, not always caught (e.g. https://github.com/doctrine/annotations/pull/56 ). This problem is shared with all our YAML-based logic with code vs YAML files (e.g. route names, service names), where kludgy IDE plugins have to be used to bridge these two realms, and core just hope all is for the best without providing builting resiliency/control mechanisms

As a comparison, code-level discovery mechanisms (e.g ServiceProvider/Modifiers, RouteSubscribers, StaticDiscovery and info hooks) have the advantage of remaining in the single code realm. They have their issues too, as we learnt especially with info hooks in D7 times, (e.g. bundle enumeration issues in entity info hook, or the lack of language-level structure from using arrays of doom), but at least their data can be more tightly bound together, and consistency/integrity has a potential for being higher.

The goal of this issue is to see if another discovery implementation, probably a code-based one, could bring an overall better set of features than annotation-based discovery. This could mean reconsidering one of the existing implementations, or possibly a new one.

Obligatory XKCD reference: https://xkcd.com/927/

Comments

fgm created an issue. See original summary.

fgm’s picture

joachim’s picture

As I said on the other issue, and probably elsewhere, I think using code comments to contain what is essentially code is crazy.

I think the simple alternative is to use a YML file to declare the plugin metadata, either one per plugin, or a manifest in the top Plugin/ folder.

We already use YML for most of our declarative stuff in Drupal, so doing this would also fix the current situation where we actually have 2 completely different systems for declaring things: YML files and annotations.

I remember a long time ago there was an objection to having a separate metadata file for a plugin, but I don't think that has much weight as an argument:

- under OO we already have a TON of files per module. The days of aiming for a module made of < 10 files are long gone
- if the idea is that plugin classes are moveable between modules, that's not really the case anyway, as you need to change the namespace for the class
- we already have a concept of having a PHP class file + something declaring it elsewhere: services, dynamic permissions, dynamic routes, etc

fgm’s picture

Separate text (YML) files are indeed the first idea which springs to mind thinking of metadata/manifests. However:

* they imply either a loss of code relationship / validation (like annotations), or a complex schema system like config schema
* there are multiple class files in most directories, so it means either one metafile per class (lots of noise) or a combined file (maintenance issues)

dawehner’s picture

One major feature of annotations is being able to translate strings using the @Translation annotation. Whatever solution we will have in the future, we need some support for translation of labels as well.

joachim’s picture

> * there are multiple class files in most directories, so it means either one metafile per class (lots of noise) or a combined file (maintenance issues)

Can you explain why a combined file is a maintenance issue? The services.yml file is a combined file that describes lots of classes.

> Whatever solution we will have in the future, we need some support for translation of labels as well.

Config schemas declared in config yaml files have translatable labels too.

It might be an idea to list features of the existing system we want to keep, such as translation, and also general pros and cons.

One pro I can think of is that current discovery system rigidly enforces a directory structure for plugins, which makes for good DX as you always know where to find plugins, in any module you look in. (Unlike forms, controllers, entity handlers, entity interfaces, which vary in their placement.)

dawehner’s picture

Can you explain why a combined file is a maintenance issue? The services.yml file is a combined file that describes lots of classes.

Menu links, actions etc. are already technically plugins defined in a single file, so at least for those we wouldn't have to come up with more technical solutions.

Config schemas declared in config yaml files have translatable labels too.

Fair, but this all depends on typed data and config translation. Bringing this to plugins would be non trivial :)

Mile23’s picture

So the point of plugins is that you don't know the mapping of an ID to a class.

If you know the relationship, you don't need a plugin system to discover it. You can just instantiate the thing you need.

For instance in the testbot, we have plugin ids which represent the steps of the build. There's a 'simpletest' plugin and a 'phpcs' plugin and so forth. We don't really need to re-discover them every time because there are a finite number of steps available. But it makes sense to have a flexible system so we can just add plugins and then also add steps to the build definition files without having to change a bunch of class names in a lot of different places. That improves DX.

In that case, it would be somewhat more efficient to have a plugin discovery layer that can take a yaml map or even just a static lookup array. I'm sure there would be other use cases for that beyond the testbot.

tim.plunkett’s picture

In that case, it would be somewhat more efficient to have a plugin discovery layer that can take a yaml map or even just a static lookup array. I'm sure there would be other use cases for that beyond the testbot.

We already have both of these, and others.
The plugin system is not as rigid as you might try to paint it.

There are 4 main implementations of discovery:
\Drupal\Core\Plugin\Discovery\AnnotatedClassDiscovery
\Drupal\Core\Plugin\Discovery\HookDiscovery
\Drupal\Core\Plugin\Discovery\YamlDiscovery
\Drupal\Component\Plugin\Discovery\StaticDiscovery

Additionally, there are decorators for each of the first 3.
So they can be combined, like in LayoutPluginManager:

      $discovery = new AnnotatedClassDiscovery('Plugin/Layout', $this->namespaces, Layout::class, $this->additionalAnnotationNamespaces);
      $discovery = new YamlDiscoveryDecorator($discovery, 'layouts', $this->moduleHandler->getModuleDirectories() + $this->themeHandler->getThemeDirectories());

This example allows:

  • modules to provide classes in /src/Plugin/Layout, annotated with @Layout
  • modules and themes to provide *.layouts.yml files

If you don't like using annotations, ask the maintainer of the plugin type to add YamlDiscoveryDecorator or InfoHookDecorator and you can specify your plugins another way.

Mile23’s picture

Yah, I mainly learned plugin stuff from working on the testbot which is frozen in time from before the subtree split. Behold: #2643110: Have drupalci_testbot require drupal/core-plugin in composer.json

Thanks.

joachim’s picture

Title: Re-architect discovery to remove the use of annotations » Devise a new discovery system for plugins, to replace the use of annotations

Good point @tim.plunkett. Current issue title does the plugin discovery system a disservice.

> If you don't like using annotations, ask the maintainer of the plugin type to add YamlDiscoveryDecorator or InfoHookDecorator and you can specify your plugins another way.

The point is though we'd like to deprecate the use of annotation discovery for plugins.

tim.plunkett’s picture

Title: Devise a new discovery system for plugins, to replace the use of annotations » Deprecate annotations, one of the four plugin discovery approaches
Category: Task » Feature request
Issue tags: +Needs issue summary update

There are 4 ways to define plugins right now. Which cover all of the suggested approaches mentioned in this issue.
You only "like" 3 of them. You think the 4th way is "crazy".

Well, good for you! But why should we remove it? Just don't write your plugins that way.


This IS is too close to the "rewrite SAR" issue, it doesn't discuss reasons to stop using annotations.

fgm’s picture

Issue summary: View changes

I tried to redo the IS to be clearer and better focused.

joachim’s picture

@tim.plunkett You're coming across a bit prickly, and I'm sorry if I've offended you. I wasn't trying to attack anyone personally; I have no idea who originally came up with the idea for using annotations as a discovery method.

Nonetheless, I stand by my opinion of annotations -- and if anything, I am making a comment on the whole existence of the Doctrine annotations library, not just our usage of it.

So your proposed solution doesn't really satisfy what I think this issue should accomplish. The annotation discovery is the most widely-used of the 4 methods, and it's seen as the defacto way of defining your plugins. To have some contrib modules start doing something else would be veering off from a core pattern, and poor DX.

What I would like to see happen is the following:

- annotation discovery is deprecated
- core plugins switch to something else, which is announced as the new principal discovery for plugins
- contrib is encouraged to follow suit

Whether such a large change is desirable in a minor version is a matter for debate, as all the core & contrib plugin types would need to keep on supporting annotation discovery for the implementations that exist in other modules to be backwards-compatible. E.g. if block plugins moved to NewDiscovery, we'd need all the block plugins defined with annotations in contrib and custom code to keep on working. It looks like that should be doable with the decorators at least.

This in the latest version of the IS I don't think is quite right:

> * either replace SimpleAnnotationReader as such (which is the topic of #2631202)
> * or go one step further replace the annotation-based discovery method itself, possibly by a mechanism not based on annotations at all.

Because of backwards compatibility, we need to keep on supporting annotations no matter what, so fixing the problems outlined in #2631202: Doctrine no longer supports SimpleAnnotationReader, incorporate a solution into core is still necessary. I don't think this issue replaces that one.

This I don't entirely agree with:

> the issue of having code at two data realms (code vs annotations), causing repetition and introducing a possibility of inconsistency, not always caught (e.g. https://github.com/doctrine/annotations/pull/56 ). This problem is shared with all our YAML-based logic with code vs YAML files (e.g. route names, service names),

Yes, annotations are a problem because they are two data realms, but also because one of those code realms is an abuse of the system. YAML is not; we're using it exactly as intended, for declarative data, it's clear to read and write, it allows comments. I think that switching all of our declarative info-type hooks to YAML was a positive change in D8 (though I admit that one negative consequence of the change is that for dynamic declarations, there's a LOT more boilerplate required).

> One major feature of annotations is being able to translate strings using the @Translation annotation.

It looks like YamlDiscovery supports translation. You declare them by calling YamlDiscovery::addTranslatableProperty(), which means it's the responsibility of the plugin manager to set that up. So that's actually a DX improvement over annotation discovery, where every single plugin has to repeat that the 'foo' property is translatable! :)

Some things that YamlDiscovery doesn't do that I would like:

- it's a bit fiddly to specify a different folder in modules to find the manifest yml file, for example if we wanted it in src/Plugins:

> $this->discovery = new YamlDiscovery('intervals', $module_handler->getModuleDirectories());

- it's one file per plugin type, whereas I can see a case for a single file src/Plugins/plugins.yml which lists all the plugins that a module provides.

- it doesn't enforce a folder structure for the plugin classes, which as I said above, I think is something really good that's come out of the way annotation discovery works.

dawehner’s picture

I think one real question this issue leads to is thinking about our basically organically grown extensibility mechanisms.
From having "just" hooks, even they had sort of different concepts, we evolved to many different solutions, all optimized for their specific usecases: Plugins, tagged services, events, other static yml files. I don't have an answer, but I think just continuing to go to the next local optima without stepping back, might not be the best picture.

While the issue summary lists a lot of problems/disagreements with annotations, I think just to be fair, we should also listen the advantages like:
a) It is really easy to create a new plugin, just copy an existing one b) Annotations, by having classes attached can provide some validation as well c) Having metadata and the class at the same place, makes it easier in some cases: find the things in the UI etc. Annotations are a local optima.

fgm’s picture

@dawehner : I wondered whether I should list the advantages too when I edited it, but felt it was rather longish already. But by all means edit it: better have a balanced summary. Although I disagree on point a), b) sound interesting although I don't think we do it anywhere, and c) is really relevant, especially versus manifest files, which is what I was trying to express: this is the big gain from StaticDiscovery IMHO: having everything pertaining to the plugin be in one place, in the code, but it also applies to annotations, minus the single-realm.

Mile23’s picture

So it seems like the conversation here is not so much whether annotation should be removed from the plugin system, but how we want to map between IDs and classes. We might find that in one circumstance, a YAML file would be best, because the relationship is relatively unchanging. In another circumstance it might be best to have annotations because the relationship is highly arbitrary

Therefore if there's a place in core where we're using annotation when it should be some other form of discovery, let's fix that in a specific scope.

joachim’s picture

> So it seems like the conversation here is not so much whether annotation should be removed from the plugin system, but how we want to map between IDs and classes.

I don't think that fully describes it.

Each plugin defines metadata, and the first and foremost piece of metadata is its ID, but then there is all the other stuff that goes into the definition. All of that is retrieved during discovery, and cached as the list of plugin definitions for that plugin type. These definitions are what allows a UI to show a list of plugin options (using labels in addition to IDs), or to determine which plugins apply to a particular circumstance.

I don't think the nature of the relationship between ID and class changes much. It's defined in code, and alterable by site builders in custom code.

> While the issue summary lists a lot of problems/disagreements with annotations, I think just to be fair, we should also listen the advantages

Yes, absolutely. I did make a start, but I only got one :)

> a) It is really easy to create a new plugin, just copy an existing one
> b) Annotations, by having classes attached can provide some validation as well
> c) Having metadata and the class at the same place, makes it easier in some cases: find the things in the UI etc. Annotations are a local optima.

Ok so having the metadata in the same file as the class is an advantage. Let's put that on the list of aspects we want to keep. (Though that does raise the question of why don't we do that for services too?)

That still doesn't mean annotations are the only way to do that or the best.

Off the top of my head, I can think of three ways:

1. Use __halt_compiler() and put a block of YAML at the end of the plugin file:


class myPlugin extends PluginBase {

}

__halt_compiler()
id: my_plugin
label: My Plugin
foo: bar

Cons:

- the metadata is at the end of the file rather than the top.
- halt_compiler() looks ugly.

2. Use class property which is a HEREDOC containing YAML. Discovery can find the property by tokenizing the file rather than loading it, and then parse the YAML


class myPlugin extends PluginBase {
	
  protected $pluginDefinition = <<<END
    id: my_plugin
    label: My Plugin
    foo: bar
END;
	
}

Cons:
- I find heredocs fiddly and easy to get wrong. But then, so are annotations! And at least IDEs and text editors will tell you if your heredoc is terminated incorrectly.

3. Use a class property which is a normal PHP array. In discovery, find the property by tokenizing the file, extract the string that's the property declaration and eval() it to get the data, so that the whole class is not loaded.


class myPlugin extends PluginBase {
	
  protected $pluginDefinition = [
    'id' => 'my_plugin',
    'label' => 'My Plugin',
    'foo' => 'bar',
  ];

}

Cons:

- extracting the metadata would be a bit ugly, but I don't think it would be much uglier that what Doctrine has to do (if at all!). Also, adding ugliness to the inner workings of a system to make a better API and DX for implementations is a choice I would *always* make.
- developers who don't know the system might think they can take the plugin definition from that property, which would bypass alteration that gets done in discovery.

That's three alternatives that I came up with while brushing my teeth last night. So I am pretty confident that the collective minds of Drupal can do better than annotations.

EclipseGc’s picture

Hey guys,

So having read this issue, I want to weigh in and see if I can't help bring this conversation to a logical consensus.

I'd like to start by saying there's a bit of what I perceive to be unintentional misinformation as well as some obvious (and genuine) uncertainty and doubt in a number of the comments. There's some suggestion here that Annotations are disliked by the majority of developers, however despite initial misgivings of many in the community, as the person who officially made the suggestion and helped write it, I can tell you that I've been approached by a number of developers who have reaffirmed to me that they've actually grown to like Annotations at this point in the cycle. (For historical purposes, it was actually damz and bojanz who initially suggested annotations to me, and after a bit of research I decided that it had great potential and chx and I did the initial implementation which was iterated on by many others including Tim).

More importantly, the plugin subsystem maintainers (Tim and myself) have no desire to see this discovery mechanism removed. It has served Drupal very well. From my own perspective dawehner's points A & C in #15 are 100% spot on and were big guiding principles in the development of the Plugin system. If I were to rewrite plugins from scratch again, I'd continue to adopt annotations as the primary mechanism by which plugins are discovered.

That being said, there seems to be a bit of anti-annotation sentiment still on this issue so let me (again) address some of those points:

the "philosophical" issue of having code in comments

We don't have code in comments. We have metadata in comments. Every other statement on this issue recognizes that there is no code being executed by the text in the annotation... you cannot, for example, eval() it and expect anything to happen.

the more concrete issue of having this code-in-comments have very limited expressivity, and essentially providing only array-level structural information, which is a problem it shares with the D7 and earlier info hooks. As a matter of comparison, yaml discovery can be slightly more expressive, including the ability to rely on a schema, and include references, all of which is already used e.g.in configschema

Ok, so we establish right away that this is no worse than D7's info hooks in terms of expressibility. I can't really give any credence to the rest of the comment since the "expressivity" of an annotation is no worse than anything in YAML. It's also a bit short sighted since a class backs every annotation, a developer can imbue that class with whatever additional validation level logic they'd like. At least 2 different plugin types in Drupal core today treat the metadata with full class returns (from the annotation) so EntityTypes and Layouts actually have an object to interact with rather than dealing with the metadata as an array. (the developer deals with the object, not just drupal internally). So there's not really any limit to the sort of logic that could be included based upon the values of the annotation. And I'll just LOL at any discussion of config schema because that's quite possibly one of the most complex and convoluted systems Drupal 8 possesses today.

a technical issue with annotation parsing which has to be done

I'll address this later in the post as this seems more "solutions focussed" rather than FUD, and I look forward to discussing it.

the issue of having code at two data realms (code vs annotations), causing repetition and introducing a possibility of inconsistency...

Ok, so you go on to acknowledge this problem isn't isolated to annotations, which in my mind goes a long way to debunking your point since I could use the same logic on YAML which you seem to like.

The point is, Annotations, like Yaml, bears more in common with serialization than code. You can map this concept to just about any serialization format. As evidence for this, take a second to think of a json discovery mechanism. It's easy. Furthermore, virtually all mainstream languages today use or are in the process of adopting language level syntax parsing of annotations for exactly the sort of tooling the plugin system does. The fact that PHP is a little behind the curve on it is likely not that surprising to anyone. Furthermore, this is common place outside of Drupal in the PHP communities at large. All these arguments were true 6 years ago when we adopted this mechanism. They have only become more true in the time since. Additionally, as I mention above (but I'll outright say now) Annotations are the most flexible, toolable and expressive of all the plugin discovery mechanics we have at our disposal today.

Despite these facts, there's a place and time for Annotations. The menu plugins are a great example of when and why YAML can be good. There was no reason to want a custom class per implementation in that case since 99% of all menu plugins run through the same class. This is to say, we have different tools for different purposes.

So, thus far I've done a lot of justifying, but none of this addresses the elephant in the room which is Doctrine, NOT Annotations. And yes, something will have to be done about Doctrine. During the development cycle of D8, we actually forked doctrine/common for a time for some of these very reasons. Forking Doctrine, applying the patches we need, and maintaining that might be our least cost to getting the solution that's best for Drupal. One of the other options is to build our own Annotation system, either via some very very savvy regular expression matching, or via our own token interpreter. I've actually been building my own AST (for fun) on top of php tokenization for a few months now. It'd be cool to go that route, but token interpretation isn't particularly trivial.

All of that to say this, in order to remove plugin annotations, you'd really want Tim or myself (or ideally both) to agree in order to move forward, and neither of us do. Rather than reopen old battles, I think it'd be better for all involved if we focussed in on solving our Doctrine problem, and if you (individually) are really annoyed by Annotations, I'm more than happy to enumerate a number of ways you could personally avoid them while still interacting with plugin types that use them. I'm sorry for any annoyance they may cause you, but none of the suggestions in this thread are a better DX mechanism, nor are any of them more flexible or capable. :-(

Eclipse

donquixote’s picture

I agree with @EclipseGc and others who defend the annotation discovery.

The advantages I see:

  • A git commit to add, modify or remove a plugin only affects one file.
  • Every file only contains one plugin - e.g. as opposed to a long yml file defining multiple plugins. This greatly reduces the potential for merge conflicts.
  • There is no risk for leftover/orphan declarations, because removing the class also removes the declaration.
  • We avoid explicit FQNs in yml files, where the IDE does not understand that these are class names, and does not support them for refactor/rename or "find usages".

The only problem I see with annotations is if they grow too big.
Huge nested structures should be defined in a format that the IDE can more easily analyze.

For the "philosophical" aspect: I don't see it as a problem. Every unorthodox solution can become commonly accepted, if it is being used enough.

About Doctrine annotations:
- Doctrine annotation library has flaws.
- They are working on version 2, https://github.com/doctrine/annotations/pull/75 I don't know if this will fix all problems. I have my concerns about this PR, but don't want to go into too much detail here.
- I am working on my own annotation discovery here, https://github.com/donquixote/annotation-parser. I don't want to promise or advertise it too much for now, because I am still working on it as we speak. My local version already looks quite different than what you see online.
- I have not fully studied #2631202: Doctrine no longer supports SimpleAnnotationReader, incorporate a solution into core, so no opinion yet.

joachim’s picture

All of those advantages you state are possible without annotations, as I showed in an earlier comment.

> For the "philosophical" aspect: I don't see it as a problem. Every unorthodox solution can become commonly accepted, if it is being used enough.

That is a *TERRIBLE* way to look at things. With that principle, we could justify ANY awful practice in our code. We could use GOTOs widely enough in our code, and learn to get used to it!]

> We don't have code in comments. We have metadata in comments. Every other statement on this issue recognizes that there is no code being executed by the text in the annotation... you cannot, for example, eval() it and expect anything to happen.

That is nitpicking. It's executable code in comments in that I can make a change to some text inside a comment and crash my site. That's a violation of the contract between the developer and PHP.

donquixote’s picture

That is a *TERRIBLE* way to look at things. With that principle, we could justify ANY awful practice in our code. We could use GOTOs widely enough in our code, and learn to get used to it!]

The reason why goto is bad is not because it is not part of the language (it is), or because someone said so, but because it clearly leads to poorly maintainable code. There is a lot of empirical evidence for this.

So perhaps I should rephrase my statement. If an unorthodox practice produces good results and is used long enough, after some time it will no longer be perceived as unorthodox.

This, per definition, excludes practices that produce bad results (like goto) and deviation from standards for no good reason (like using a different indentation level than the rest of the world, just because you feel like it)

All of those advantages you state are possible without annotations, as I showed in an earlier comment.

This would be #18.

In fact when I first heard of annotations, I had similar ideas. I think my idea was something with a static method.

The main benefit I see with annotations living in doc comments is that
- they do not interfere with regular code execution.
- the class file still has the structure of a regular class file.

In your proposed alternatives 2. and 3., you want to express the metadata via regular language features.
But then you want to read this data with an external parser, circumventing regular code execution.
Even though the property (or a static method, as I would do it) is visible at runtime, you do not actually want it to be used as such, ever.
In fact, you would prefer something that is invisible at runtime.

This is exactly why we want something outside the regular language, something that is guaranteed to have no direct effect on runtime code.

That's three alternatives that I came up with while brushing my teeth last night. So I am pretty confident that the collective minds of Drupal can do better than annotations.
Or rather, that the PHP community would have already come up with.

Doctrine-style annotations in doc comments have been known for a while, within and outside the Drupal community. There are even IDE plugins which tell you about available properties in annotation classes.

And, look here: https://wiki.php.net/rfc/annotations
I currently don't have a clear opinion about this rfc. But it is obvious that at this time we cannot use this for Drupal 8.

So in fact I am confident that annotations in doc comments are the best option we have currently available.

(Though that does raise the question of why don't we do that for services too?)

Or for routes, or menu links, or anything that we currently use yml files for.
I personally see no fundamental reason why this should be taboo, except that some people won't like it.
I think a lot of the pros and cons are the same as for plugins.

A central yml file (per module) gives an overview what the module has to offer. And it means the discovery only needs to look at this one file (per module), not scan the entire namespace directory.
yml discovery does not need to care about class loading or namespace/directory mappings, and it does not need artificial reflection. The yml discovery mechanism is clearly simpler.

-----------

All of this being said:

  • I think in many cases we often have too much data in those annotations.
    For my taste, the average annotation should have an id and a label, and not much more.
  • For a while I found the idea that an annotation name is a class name a bit strange.
    But I made my peace with it, because my IDE supports it :)
  • I am not fully happy with the architecture of the doctrine\annotation library. But as long as it does the job, I say whatever.

So if we want to improve some aspects of how we use annotations, sure. But to get rid of them completely, I disagree.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

heddn’s picture

Issue summary: View changes

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

andypost’s picture

Issue tags: +PHP 8.0, +Symfony 6

Symfony added support for native php 8 annotations https://symfony.com/blog/new-in-symfony-5-2-php-8-attributes

fgm’s picture

I guess this means at least Drupal 10 because we can't require PHP 8 before that, can we ?

tim.plunkett’s picture

I think this issue should be closed as won't fix, and a D10 issue about converting to PHP8 annotations should be opened.

andypost’s picture

Deprecation could be done only when new implementation will work

Meanwhile doctrine working on next version, but both require to load classes which is less performant then current forked discovery

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

andypost’s picture

longwave’s picture

We also already have phpdocumentor/reflection-docblock as a dev dependency, which looks like it also loads classes, but might be an alternative to Doctrine.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

xjm’s picture

Status: Active » Closed (won't fix)

Won't fix per #31.

andypost’s picture

FTR the suggested follow-up in #31 to use native attributes is #3252386: Use PHP attributes instead of doctrine annotations