[Translation] Moved PhpExtractor and PhpStringTokenParser to Translation component #24197
Conversation
| */ | ||
| class PhpExtractor extends AbstractFileExtractor implements ExtractorInterface | ||
| class PhpExtractor extends \Symfony\Component\Translation\Extractor\PhpExtractor |
There was a problem hiding this comment.
this doesn't work as a BC layer: PhpExtractor instanceof PhpExtractor should be true whatever the namespaces.
the proper way to do so is using class_alias+class_exists.
see BC layer of ChildDefinition/DefinitionDecorator as an example.
There was a problem hiding this comment.
Well, the issue with class_alias is that you won't get a deprecation warning when using the old class name if the new one was autoloaded first.
For PhpExtractor, support for ComponentExtractor instanceof BundleExtractor is not needed IMO, as extractors are not really something you inspect this way (you instantiate them to pass them to the extraction layer).
We have many cases where we create a new class and make the deprecated one extend the new one.
44a83a1 to
4407cd3
Compare
4407cd3 to
eca2f8e
Compare
|
Thank you @Nyholm. |
…ser to Translation component (Nyholm) This PR was merged into the 3.4 branch. Discussion ---------- [Translation] Moved PhpExtractor and PhpStringTokenParser to Translation component | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | yes | Tests pass? | yes | Fixed tickets | | License | MIT | Doc PR | Extraction of translations keys does not really belong to the framework bundle. It is related to the translation component. Commits ------- eca2f8e Moved PhpExtractor and PhpStringTokenParser to Translation component
Extraction of translations keys does not really belong to the framework bundle. It is related to the translation component.