Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[meta] Annotations 2.0 (ng) #232

Closed
8 of 27 tasks
Majkl578 opened this issue Dec 18, 2018 · 10 comments
Closed
8 of 27 tasks

[meta] Annotations 2.0 (ng) #232

Majkl578 opened this issue Dec 18, 2018 · 10 comments

Comments

@Majkl578
Copy link
Contributor

Majkl578 commented Dec 18, 2018

Annotations 2.0 (ng)

This is a meta issue to track Annotations 2.0 milestones/features and aims. It's also a follow-up of #75 which collected some dust over time.

Backward Compatibility

One of the main goals of the 2.0 version is on minimizing breakages of existing annotations and syntax compatibility with Annotations 1.x. Therefore, when talking about custom annotations and docblocks, most of the user-land stuff should work without any significant effort or none at all. However most of the internal stuff is expected to be changed.

Namespace change

Dropped features

Some features will be dropped:


New parser

Initial work is split into three different stages and will come as a new code without refactoring existing stuff:

  1. Parser - this is the docblock parser
    • PP language - Doctrine Annotations syntax definition
    • Compiler - docblock to AST converter
    • AST structure - rich domain-specicic AST
    • AST builder - internal AST walker that builds rich AST
    • AST walker - interface for traversing AST
    • AST dumper- utility walker to display AST structure
    • Parser parity tests - compatibility testing between old and new parsers
  2. Metadata - this represents an @Annotation
    • Annotation and Property metadata - information needed to construct annotation objects [Introduce annotation metadata #247]
    • Property type and enum hiearchy [Type hiearchy for property types and enums #256]
    • AST metadata collector (walker)
    • Scope - holds information about subject (origin), active imports, ignored annotations and nesting level
    • Reference resolver - resolves unqualified annotation references based on given scope and strategy
    • Property type parser - parses @var to constraint value types
  3. Assembling
    • Annotation assembler - builds actual annotation objects based on AST and metadata
    • Acceptor - determines whether visited annotation AST node should produce an annotation or be skipped (used to build internal/public or skip ignored annotations)
    • Constraint validator - validates annotation's property values against constraints (i.e. Required, Enum, @var)
    • Constructor - instantiates annotation objects based on chosen strategy (using a constructor or using property hydration)

Other problems to likely be resolved (but not guaranteed)

Generally issues marked with 2.0 milestone. Notably:


Any feedback is welcomed, either here or (preferably) on Doctrine Slack in #annotations-ng-dev channel.

@Majkl578 Majkl578 added this to the v2.0.0 milestone Dec 18, 2018
@Majkl578 Majkl578 pinned this issue Dec 18, 2018
@alcaeus
Copy link
Member

alcaeus commented Dec 18, 2018

The namespace will be changed from Doctrine\Common\Annotations to Doctrine\Annotations

This was a hotly contested issue in the last attempt to create 2.0, so I'll just link previous discussion: #75 (comment).

FileCacheReader - dropped in favor of doctrine/cache

If with "dropped in favour of" you mean "implemented generically for any doctrine/cache instance", then I can somewhat live with the change. We should also consider shipping readers that use a PSR-16 or PSR-6 cache given to them.

@stof
Copy link
Member

stof commented Dec 18, 2018

* `FileCacheReader` - _dropped in favor of doctrine/cache_

this should read as dropped in favor of CachedReader instead, as the replacement is CachedReader (which already exists in 1.x)

@Majkl578
Copy link
Contributor Author

@stof Thanks, updated.

@jaapio
Copy link

jaapio commented Dec 20, 2018

Why write your own docblock parser if the new phpdocumentor docblock parser is able to cover your back? Would be happy to assist with changes if needed

@stof
Copy link
Member

stof commented Dec 20, 2018

@jaapio doctrine annotation are not the same than phpdoc. The phpdocumentor parser cannot replace the Doctrine annotation parser.

@jaapio
Copy link

jaapio commented Dec 20, 2018

With the new design of the package we left room for annotations. Don't know if it would make any sense for you guys.

@piotrooo
Copy link

What is a current state of this milestones?

@Majkl578
Copy link
Contributor Author

@piotrooo I've cleaned up master (2.0-dev) where namespace has already been changed and most of the deprecated stuff has been dropped too. Now working on introducing new stuff to prepare for the parser replacement.
I also slightly updated the OP.

@piotrooo
Copy link

@Majkl578 have you any tasks to do? I can help with that release.
BTW. Thanks for good work.

@Majkl578
Copy link
Contributor Author

After recent events I no longer intend to work on this. Sorry everyone.

sanmai added a commit to sanmai/annotations that referenced this issue Jun 28, 2019
As v2 isn't here yet, and looking at doctrine#232 it is unclear if will, and as we have to put up with annoying deprecated functions, here I propose to fall back to the standard autoloader if nothing else worked, and if there's no custom loader defined.

Fixes doctrine#270
@alcaeus alcaeus unpinned this issue Jan 18, 2020
alcaeus pushed a commit to sanmai/annotations that referenced this issue Apr 1, 2020
As v2 isn't here yet, and looking at doctrine#232 it is unclear if will, and as we have to put up with annoying deprecated functions, here I propose to fall back to the standard autoloader if nothing else worked, and if there's no custom loader defined.

Fixes doctrine#270
alcaeus pushed a commit to sanmai/annotations that referenced this issue Apr 2, 2020
As v2 isn't here yet, and looking at doctrine#232 it is unclear if will, and as we have to put up with annoying deprecated functions, here I propose to fall back to the standard autoloader if nothing else worked, and if there's no custom loader defined.

Fixes doctrine#270
alcaeus added a commit that referenced this issue Apr 2, 2020
* Trigger the standard autoloader as the last resort

As v2 isn't here yet, and looking at #232 it is unclear if will, and as we have to put up with annoying deprecated functions, here I propose to fall back to the standard autoloader if nothing else worked, and if there's no custom loader defined.

Fixes #270

* Do not use standard autoloader with registerFile()

* Add tests for fallback autoloading

* Update deprecation messages

* Update AnnotationRegistry.php

Co-authored-by: Andreas Braun <git@alcaeus.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants