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

[Messenger] Don't make EnvelopeItemInterface extend Serializable#28247

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

Merged

Conversation

@nicolas-grekas
Copy link
Member

@nicolas-grekasnicolas-grekas commentedAug 23, 2018
edited
Loading

QA
Branch?master
Bug fix?no
New feature?no
BC breaks?yes (on experimental API)
Deprecations?no
Tests pass?yes
Fixed tickets-
LicenseMIT
Doc PR-

Serializable is a broken interface, see e.g.https://externals.io/message/98834
I don't think we should force ppl to implement it anywhere.
Actually, it isn't required to be able to serialize an object, and it doesn't enforce making a class serializable (as theserialize() method can throw).

What was the purpose of the removed logic? ping@sroze@ogizanagi

@linaori
Copy link
Contributor

Should this be done in 5.0 for other classes as well? I haven't done a full search across the codebase, but I know that at least the TokenInterface does this.

@nicolas-grekas
Copy link
MemberAuthor

@iltar yep, but unfortunately those are not experimental anymore. I'd love to remove the "extends" also. Can we?

@linaori
Copy link
Contributor

I'm not sure if the serialize/unserialize methods will be calledwithout the interface. What wecould do, is implement the methods in the interface extending\Serializable and mark it as deprecated in there. In any core-class extending this class, we can also throw a deprecation during serializing/unserializing. Downside is that you can't fix this deprecation until you've upgraded to the next major. Perhaps there are other solutions, but those won't be pretty (run-time class generation etc)

Copy link
Contributor

@srozesroze left a comment
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Yes, we tried and already see the limits (like in#28164 for example) so let's remove theSerializable (so we can even provide the opportunity to use the Symfony Serializer instead of(un)serialize 👌)

@nicolas-grekas can you update the CHANGELOG & UPGRADE files?

@nicolas-grekas
Copy link
MemberAuthor

CHANGELOG & UPGRADE updated

Copy link
Contributor

@ogizanagiogizanagi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

@nicolas-grekas : Purpose was to keep serialization under control and make users think about how to serialize it reliably. Otherwise, PHP serialization is a mess in case of refactoring and for BC layers.
But actually, I'm fine with removing it, you're right.

@fabpot
Copy link
Member

Thank you@nicolas-grekas.

@fabpotfabpot merged commit2beda89 intosymfony:masterAug 27, 2018
fabpot added a commit that referenced this pull requestAug 27, 2018
…rializable (nicolas-grekas)This PR was merged into the 4.2-dev branch.Discussion----------[Messenger] Don't make EnvelopeItemInterface extend Serializable| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | no| BC breaks?    | yes (on experimental API)| Deprecations? | no| Tests pass?   | yes| Fixed tickets | -| License       | MIT| Doc PR        | -`Serializable` is a broken interface, see e.g.https://externals.io/message/98834I don't think we should force ppl to implement it anywhere.Actually, it isn't required to be able to serialize an object, and it doesn't enforce making a class serializable (as the `serialize()` method can throw).What was the purpose of the removed logic? ping@sroze@ogizanagiCommits-------2beda89 [Messenger] Don't make EnvelopeItemInterface extend Serializable
@nicolas-grekasnicolas-grekas deleted the messenger-drop-serializable branchAugust 30, 2018 15:24
fabpot added a commit that referenced this pull requestSep 4, 2018
…elope items (sroze)This PR was merged into the 4.2-dev branch.Discussion----------[Messenger] Uses Symfony Serializer by default for envelope items| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | yes| BC breaks?    | yes| Deprecations? | no| Tests pass?   | yes| Fixed tickets |#28164| License       | MIT| Doc PR        | øThe original approach was to use `serialize`/`unserialize` for envelope items. It turns out it has limitations (see#28247) and reduces the compatibility with 3rd party systems (see#28164). This pull-request changes the existing mechanism by using Symfony Serializer by default.It keeps the `serialize`/`unserialize` mechanism to allow users of the experimental component to keep using it in 4.2 and allow to have a non-disruptive upgrade to 4.2.Commits-------9b575ab Uses Symfony Serializer by default for envelope items
@nicolas-grekasnicolas-grekas modified the milestones:next,4.2Nov 1, 2018
This was referencedNov 3, 2018
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@fabpotfabpotfabpot approved these changes

+2 more reviewers

@srozesrozesroze approved these changes

@ogizanagiogizanagiogizanagi approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

4.2

Development

Successfully merging this pull request may close these issues.

6 participants

@nicolas-grekas@linaori@fabpot@sroze@ogizanagi@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp