-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
Add missing autoload calls #35728
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
Merged
Merged
Add missing autoload calls #35728
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
8551073
to
2a40ba8
Compare
stof
approved these changes
Feb 14, 2020
4.3 is EOLed. |
Until either php 7.4 or doctrine/persistence 2 is required, these will be needed to make sure php recognises signatures using the old names as compatible with signatures using the new names. This is necessary for types defined outside Symfony that extend types from Symfony and still use the old names in signatures of methods they override. More details at https://dev.to/greg0ire/how-to-deprecate-a-type-in-php-48cf Fixes doctrine/DoctrineMongoDBBundle#616
2a40ba8
to
94b5dbd
Compare
I picked 4.4 because 3.4 does not use the new type declarations. |
greg0ire
added a commit
to greg0ire/DoctrineMongoDBBundle
that referenced
this pull request
Feb 14, 2020
A backwards-compatibility layer has been added to persistence to help consumers move to the new namespacing. It is based on class aliases, which means the type declaration changes should not be a BC-break: types are the same. See doctrine/persistence#71 This means: - using the new namespaces - adding autoload calls for new types to types that may be extended and use persistence types in methods signatures for which compatibility checks may happen, so that signature compatibility is recognized by old versions of php. More details on this at https://dev.to/greg0ire/how-to-deprecate-a-type-in-php-48cf Fixes doctrine#616 as a side effect, but the real fix is at symfony/symfony#35728
greg0ire
added a commit
to greg0ire/DoctrineMongoDBBundle
that referenced
this pull request
Feb 14, 2020
A backwards-compatibility layer has been added to persistence to help consumers move to the new namespacing. It is based on class aliases, which means the type declaration changes should not be a BC-break: types are the same. See doctrine/persistence#71 This means: - using the new namespaces - adding autoload calls for new types to types that may be extended and use persistence types in methods signatures for which compatibility checks may happen, so that signature compatibility is recognized by old versions of php. More details on this at https://dev.to/greg0ire/how-to-deprecate-a-type-in-php-48cf Fixes doctrine#616 as a side effect, but the real fix is at symfony/symfony#35728
greg0ire
added a commit
to greg0ire/DoctrineMongoDBBundle
that referenced
this pull request
Feb 14, 2020
A backwards-compatibility layer has been added to persistence to help consumers move to the new namespacing. It is based on class aliases, which means the type declaration changes should not be a BC-break: types are the same. See doctrine/persistence#71 This means: - using the new namespaces - adding autoload calls for new types to types that may be extended and use persistence types in methods signatures for which compatibility checks may happen, so that signature compatibility is recognized by old versions of php. More details on this at https://dev.to/greg0ire/how-to-deprecate-a-type-in-php-48cf Fixes doctrine#616 as a side effect, but the real fix is at symfony/symfony#35728
fabpot
approved these changes
Feb 15, 2020
Thank you @greg0ire. |
fabpot
added a commit
that referenced
this pull request
Feb 15, 2020
This PR was merged into the 4.4 branch. Discussion ---------- Add missing autoload calls Until either php 7.4 or doctrine/persistence 2 is required, these will be needed to make sure php recognises signatures using the old names as compatible with signatures using the new names. This is necessary for types defined outside Symfony that extend types from Symfony and still use the old names in signatures of methods they override. Fixes doctrine/DoctrineMongoDBBundle#616 | Q | A | ------------- | --- | Branch? | 4.3 | Bug fix? | yes | New feature? | no <!-- please update src/**/CHANGELOG.md files --> | Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tickets | Fix doctrine/DoctrineMongoDBBundle#616 | License | MIT | Doc PR | n/a <!-- Replace this notice by a short README for your feature/bugfix. This will help people understand your PR and can be used as a start for the documentation. Additionally (see https://symfony.com/releases): - Always add tests and ensure they pass. - Never break backward compatibility (see https://symfony.com/bc). - Bug fixes must be submitted against the lowest maintained branch where they apply (lowest branches are regularly merged to upper ones so they get the fixes too.) - Features and deprecations must be submitted against branch master. --> This topic is fairly complicated, more details at https://dev.to/greg0ire/how-to-deprecate-a-type-in-php-48cf Commits ------- 94b5dbd Add missing autoload calls
greg0ire
added a commit
to greg0ire/DoctrineMongoDBBundle
that referenced
this pull request
Mar 15, 2020
A backwards-compatibility layer has been added to persistence to help consumers move to the new namespacing. It is based on class aliases, which means the type declaration changes should not be a BC-break: types are the same. See doctrine/persistence#71 This means: - using the new namespaces - adding autoload calls for new types to types that may be extended and use persistence types in methods signatures for which compatibility checks may happen, so that signature compatibility is recognized by old versions of php. More details on this at https://dev.to/greg0ire/how-to-deprecate-a-type-in-php-48cf Fixes doctrine#616 as a side effect, but the real fix is at symfony/symfony#35728
fabpot
added a commit
that referenced
this pull request
Nov 27, 2020
…ire) This PR was merged into the 5.2 branch. Discussion ---------- [DoctrineBridge] Require doctrine/persistence 2 | Q | A | ------------- | --- | Branch | 5.x | Bug fix | no | New feature | no <!-- please update src/**/CHANGELOG.md files --> | Deprecations | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tickets | n/a | License | MIT | Doc PR | n/a This allows us to remove autoload calls that are necessary for the persistence 1 backwards-compatibility layer to work. This is a follow up of #35728 Commits ------- 574a184 Require doctrine/persistence 2
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Until either php 7.4 or doctrine/persistence 2 is required, these will
be needed to make sure php recognises signatures using the old names as
compatible with signatures using the new names.
This is necessary for types defined outside Symfony that extend types
from Symfony and still use the old names in signatures of methods they
override.
Fixes doctrine/DoctrineMongoDBBundle#616
This topic is fairly complicated, more details at https://dev.to/greg0ire/how-to-deprecate-a-type-in-php-48cf