Skip to content
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

Add support for custom object serialization #60

Merged
merged 2 commits into from
Aug 14, 2021

Conversation

TRowbotham
Copy link
Contributor

This adds support for the custom object serialization feature added in PHP 7.4. This is needed to suppress deprecation warnings in PHP 8.1 since the Serializable interface is now deprecated.

@BenMorel BenMorel merged commit 6dac159 into brick:master Aug 14, 2021
@BenMorel
Copy link
Member

Excellent job, thank you! 👍

@BenMorel
Copy link
Member

Actually, I'm realizing that this is somehow a BC break, because the serialized string is different (people may store serialized strings in database for example, so unserialization may break after this change), so this will need to go into the next version, 0.10.0.

I'm hesitating between releasing 0.10 now, with just this change, or waiting for 6 December when support for PHP 7.3 will be dropped, and making PHP 7.4 the minimum version and dropping Serializable at the same time.

PHP 8.1 should be released somewhere around 25 November, so the timing may be good to do everything at the same time.

What do you think?

@TRowbotham
Copy link
Contributor Author

That's a good question! I wasn't sure, so I checked the RFC and, assuming I'm understanding it correctly, this is actually not a BC break so long as the objects continue to implement Serializable. So, I think it would be fine if you released a new version now, which would potentially give developers time to convert any older serialized forms that they may have stored to the new version.

If a class both implements Serializable and __serialize()/__unserialize(), then serialization will prefer the new mechanism, while unserialization can make use of either, depending on whether the C (Serializable) or O (__unserialize) format is used. As such, old serialized strings encoded in C format can still be decoded, while new strings will be produced in O format.

@BenMorel
Copy link
Member

BenMorel commented Aug 15, 2021

I guess it is a BC break if you cannot serialize an object with one version and unserialize it with the next version?

Now that I think about it, it's actually making things worse if I release a version that's compatible with both serialization methods at the same time. Think about it:

  • I release version 0.10, compatible with PHP 7.1+ and both serialization methods
  • someone uses version 0.10 with PHP 7.3, serialize the object (serialize()), store it in the DB
  • they upgrade to PHP 7.4, keep the same brick/math version, unserialize the object (__unserialize()) from the DB : boom 💥

Oh wow, scratch that. I read your comment but not the quoted string. So you're right, it's absolutely not a BC break.

@BenMorel
Copy link
Member

Released as 0.9.3!

@TRowbotham
Copy link
Contributor Author

It will eventually become a BC break when Serializable gets removed from the language, but that may not be until PHP 9 or later.

@BenMorel
Copy link
Member

I will have dropped support for PHP < 7.4 and therefore Serializable before then ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants