| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| rfc:custom_object_serialization [2019/02/19 10:42] – Expand magic method section nikic | rfc:custom_object_serialization [2019/03/22 09:43] (current) – Implemented nikic |
|---|
| * Date: 2019-01-24 | * Date: 2019-01-24 |
| * Author: Nikita Popov <nikic@php.net> | * Author: Nikita Popov <nikic@php.net> |
| * Status: Under Discussion | * Status: Implemented (in PHP 7.4) |
| * Target Version: PHP 7.4 | |
| * Implementation: https://github.com/php/php-src/pull/3761 | * Implementation: https://github.com/php/php-src/pull/3761 |
| |
| This proposal uses magic methods for two reasons. First, they interoperate well. ''%%__serialize()%%'' and ''%%__unserialize()%%'' can be added to a class without compatibility concerns: They will be used on PHP 7.4 or newer and ignored on PHP 7.3 or older. Using an interface instead requires either raising the version requirement to PHP 7.4, or dealing with the definition of a stub interface in a compatible manner. | This proposal uses magic methods for two reasons. First, they interoperate well. ''%%__serialize()%%'' and ''%%__unserialize()%%'' can be added to a class without compatibility concerns: They will be used on PHP 7.4 or newer and ignored on PHP 7.3 or older. Using an interface instead requires either raising the version requirement to PHP 7.4, or dealing with the definition of a stub interface in a compatible manner. |
| |
| Second, they are semantically more correct. In PHP all objects are serializable by default. The ''Serializable'' interface is a complete misnomer in that sense, because an object that does not implement ''Serializable'' can be (and usually is) still serializable. On the contrary, ''Serializable'' might be implemented specifically for the purpose of forbidding serialization, by throwing an exception. The magic methods ''%%__serialize()%%'' and ''%%__unserialize()%%'' are just hooks to customize the serialization functionality, they do not determine whether an object can be serialized, and code should generally have no reason to check for their presence. | Second, they are semantically more correct. In PHP all objects are serializable by default. The ''Serializable'' interface is a misnomer in that sense, because an object that does not implement ''Serializable'' can be (and usually is) still serializable. On the contrary, ''Serializable'' might be implemented specifically for the purpose of forbidding serialization, by throwing an exception. The magic methods ''%%__serialize()%%'' and ''%%__unserialize()%%'' are just hooks to customize the serialization functionality, they do not determine whether an object can be serialized, and code should generally have no reason to check for their presence or absence. |
| |
| ==== Creating objects in __unserialize() ==== | ==== Creating objects in __unserialize() ==== |
| ===== Vote ===== | ===== Vote ===== |
| |
| Include the proposed serialization mechanism in PHP 7.4? A 2/3 majority will be required. | Voting started 2019-03-01 and ends 2019-03-15. |
| | |
| | <doodle title="Include proposed serialization mechanism in PHP 7.4?" auth="nikic" voteType="single" closed="true"> |
| | * Yes |
| | * No |
| | </doodle> |