Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103852
MIME-Version: 1.0
References: <CAF+90c-GfwWSJ+LUUYrb6gpZRrwP=XX=hWFD9DL-3xQhBOgp+A@mail.gmail.com>
 <CADyq6sLq27dT6VRB59ihJhHUanDvwDUnHAdPE6Q6vWXsbYrRfw@mail.gmail.com> <ef265d7b-d480-e7fb-12e0-c1d7e6f4cad1@php.net>
In-Reply-To: <ef265d7b-d480-e7fb-12e0-c1d7e6f4cad1@php.net>
Date: Sun, 27 Jan 2019 17:37:23 +0100
Message-ID: <CAOWwgpmXkM=P5w+m3wd6YncCkiNapwm2rxvmPgTpRq-vWW7PiQ@mail.gmail.com>
To: Sebastian Bergmann <sebastian@php.net>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007353830580732de4"
Subject: Re: [PHP-DEV] [RFC] New custom object serialization mechanism
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--0000000000007353830580732de4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le jeu. 24 janv. 2019 =C3=A0 15:18, Sebastian Bergmann <sebastian@php.net> =
a
=C3=A9crit :

> Am 24.01.2019 um 15:09 schrieb Marco Pivetta:
> > Not really fussed about having another implicit interface for
> serialization
> > (via magic methods).
>
> I second that emotion.
>


The more I think about it, the more I'm convinced we should *not* add an
interface for that.
An interface defines a semantics - something that an API tpoa domain and
that ppl can type-hint for to get a specific implementation of that
API.Here, both aspects are not desired: we don't want ppl to type-hint for
e.g. Serializable - and too bad it exists because I've already seen ppl
think: "hey, I'll type-hint or extend it to express I want a serializable
thing". BUT that's *not* the contract of Serializable or any variant of it
because: 1. *any* PHP object is serializable 2. Serializable it well
allowed to throw an exception to exactly *forbid* an object from being
serialized.

From this reasoning, I conclude that we really want magic methods here
because what we need is a *behavior*. We want to hook into the engine to
benefit from some special features it provides. That's what all magic
methods are about and hooking into serialize()/unserialize() is not
different.

The parallel with the Symfony Serializer is interesting but it stop here:
we don't need any help from core to build it. We should not seek for that
goal IMHO as it blur the lines of what we're needing: a core primitive to
build more useful things.

Magic methods would just provide that, without polluting the semantics
space.

My 2cts,
Nicolas

--0000000000007353830580732de4--