Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103858
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> <CAOWwgpmXkM=P5w+m3wd6YncCkiNapwm2rxvmPgTpRq-vWW7PiQ@mail.gmail.com>
In-Reply-To: <CAOWwgpmXkM=P5w+m3wd6YncCkiNapwm2rxvmPgTpRq-vWW7PiQ@mail.gmail.com>
Date: Mon, 28 Jan 2019 08:58:05 +0100
Message-ID: <CADyq6sK7LDHub+eJQ3dVhBA_zigZacXP9SFyY5B4tysBie5Qgg@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: Sebastian Bergmann <sebastian@php.net>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001850b70580800aad"
Subject: Re: [PHP-DEV] [RFC] New custom object serialization mechanism
From: ocramius@gmail.com (Marco Pivetta)

--0000000000001850b70580800aad
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Jan 27, 2019 at 5:37 PM Nicolas Grekas <nicolas.grekas+php@gmail.co=
m>
wrote:

> 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.


An interface declares an API surface for an object: in this case, the
consumer would be `serialize()` or `unserialize()`, and that's a perfectly
valid use-case scenario.


> 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".


That's actually a very correct thing to do: by declaring that something is
`Serializable`, you are expressing your intent to anybody inspecting the
structure of the object.


> 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.
>

That's a completely different problem, which is that PHP has no way to
declare APIs as functionally pure, or exception-less. That's something to
be explored, in my opinion, but the lack of it does not warrant dismissing
interfaces altogether (your current argument).

Serializability is something to be declared: currently, PHP is very much
ill-designed on this particular scope, but that doesn't mean that we should
make it even worse.

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.
>

Yet more magic methods just add an impressive amount of complexity to the
language (I'm already thinking of the permutations of edge cases that I'm
personally going to have to write).
It's yet another way to define something that would work correctly if an
interface (existing mechanism defined by the language) was used instead.

Magic methods would just provide that, without polluting the semantics
> space.
>

The newly introduced magic methods pollute the entire **language
semantics**: now you have another edge case in the language, instead of an
interface that works in combination with the `serialize()` and
`unserialize()` functions.

I'll also add that the problem being solved is much smaller than the issues
introduced by the proposed additions.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--0000000000001850b70580800aad--