Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[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 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 1 commit into from
Aug 27, 2018

Conversation

nicolas-grekas
Copy link
Member

@nicolas-grekas nicolas-grekas commented Aug 23, 2018

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/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 the serialize() method can throw).

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

@linaori
Copy link
Contributor

linaori commented Aug 23, 2018

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.

interface TokenInterface extends \Serializable

@nicolas-grekas
Copy link
Member Author

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

@linaori
Copy link
Contributor

linaori commented Aug 23, 2018

I'm not sure if the serialize/unserialize methods will be called without the interface. What we could 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

@sroze sroze left a comment

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 the Serializable (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
Member Author

CHANGELOG & UPGRADE updated

Copy link
Contributor

@ogizanagi ogizanagi 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

fabpot commented Aug 27, 2018

Thank you @nicolas-grekas.

@fabpot fabpot merged commit 2beda89 into symfony:master Aug 27, 2018
fabpot added a commit that referenced this pull request Aug 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/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 the `serialize()` method can throw).

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

Commits
-------

2beda89 [Messenger] Don't make EnvelopeItemInterface extend Serializable
@nicolas-grekas nicolas-grekas deleted the messenger-drop-serializable branch August 30, 2018 15:24
fabpot added a commit that referenced this pull request Sep 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-grekas nicolas-grekas modified the milestones: next, 4.2 Nov 1, 2018
This was referenced Nov 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants