Am 08.12.20 um 18:40 schrieb Larry Garfield:
> For serialization, we'll introduce a new serialization marker, enum, which 
> will make it feasible too round-trip an enum while maintaining 
> singleton-ness.  More specifically, the deserialize routine would essentially 
> become $type::from($value), where $type and $value are pulled from the 
> serialized version.

I wonder whether this mechanism could be generalized to a serialization
mechanism that would allow e.g. Database Repositories to pull entities
from a database upon unserialization.

My example would something like this (simplified):

interface IdentifierBasedSerializable {
    static function serializeToIdentifier(self $object) : string;
    static function unserializeFromIdentifier(string $identifier) : self
}


class ExternallyStoredEntity implements IdentifierBasedSerializable {
    static function serializeToIdentifier(self $object) : string {
        return $object->id;
    }

    static function unserializeFromIdentifier(string $identifier): self{
        if (!\array_key_exists($identifier, self::$objectCache)) {
            self::$objectCache[$identifier] = new self($identifier);
        }
        return self::$objectCache[$identifier];
    }

    private static $objectCache = [];
    public string $id;

    public function __construct(string $id) { $this->id = $id; }
}

Until now it is not possible to unserialize an object to the canonical
instance created earlier in the program execution.
Serialization and subsequent unserialization breaks object identity
($a->id === $b->id <=> $a === $b) that is often desired when working
with objects that represent external entities. The list of allowed enum
values is in this regard a very simple database of identifiers.

I know that passing a complex serialization string to a static
unserialization factory method has the serious problem that circular
references can not be handled. But using only an identifier as the sole
contents of the serialization string avoids this problem entirely.

Greets
Dennis

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to