Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[DX] [PropertyInfo] Filter PropertyInfo Extractors with Interfaces#16890

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Closed
zanbaldwin wants to merge1 commit intosymfony:2.8fromzanbaldwin:feature/property-info-extractor-interfaces
Closed

[DX] [PropertyInfo] Filter PropertyInfo Extractors with Interfaces#16890

zanbaldwin wants to merge1 commit intosymfony:2.8fromzanbaldwin:feature/property-info-extractor-interfaces

Conversation

@zanbaldwin
Copy link
Member

QA
Bug fix?No
New feature?No
BC breaks?Yes
Deprecations?No
Tests pass?Yes
Fixed ticketsN/A
LicenseMIT
Doc PRsymfony/symfony-docs#5974

To improve developer experience, require just one collection of extractors that filters by the interfaces that have been implemented on each extractor.

  • Simplifies registering new extractors in the service container.
  • Reduces duplication of semantics (intent defined by interfaces implemented, instead of interfaces implementedand service container tag).
  • PreventsCall to undefined method fatal errors for extractors defined with the wrong service container tag.

However, thisdoes break backwards-compatibility for:

I'm suggesting this change purely in the unlikely event that the PropertyInfo component can be classed as internal, since documentation is still pending.

/cc@dunglas

Use a single service tag to filter a central source of information extractor instances.Since PropertyInfo requires PHP 5.5+, use ::class constant to negate the use of class constants or strings.
@dunglas
Copy link
Member

It is not possible because it doesn't handle every use cases, see#15858 (comment) and my reply for details.

@zanbaldwin
Copy link
MemberAuthor

You're absolutely right, I didn't take into account different ordering for different types.
I learnt more about the FrameworkBundle whilst writing this PR, so at least it wasn't a waste 😄

@dunglas
Copy link
Member

But as you're the second person asking why after@fabpot, it can be a good idea to mention it in the doc :-)

@zanbaldwin
Copy link
MemberAuthor

I'll update the documentation PR to include the explanation in your comment, since it's an important but not immediately obvious decision.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@zanbaldwin@dunglas@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp