Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103859
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>
 <CADyq6sK7LDHub+eJQ3dVhBA_zigZacXP9SFyY5B4tysBie5Qgg@mail.gmail.com>
In-Reply-To: <CADyq6sK7LDHub+eJQ3dVhBA_zigZacXP9SFyY5B4tysBie5Qgg@mail.gmail.com>
Date: Mon, 28 Jan 2019 09:31:21 +0100
Message-ID: <CAOWwgpkEf=_zuEHY2x9s9=N9g+8hZrS6hjfqw4whtbT9XsjwQg@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: Sebastian Bergmann <sebastian@php.net>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000e9b5905808081e5"
Subject: Re: [PHP-DEV] [RFC] New custom object serialization mechanism
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--0000000000000e9b5905808081e5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

(I should have reviewed myself in the first message - sentences edited in
this reply)

Le lun. 28 janv. 2019 =C3=A0 08:58, Marco Pivetta <ocramius@gmail.com> a =
=C3=A9crit :

> On Sun, Jan 27, 2019 at 5:37 PM Nicolas Grekas <
> nicolas.grekas+php@gmail.com> wrote:
>
>> Le jeu. 24 janv. 2019 =C3=A0 15:18, Sebastian Bergmann <sebastian@php.ne=
t> 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 - an API to a 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 perfectl=
y
> valid use-case scenario.
>

Implemeting serialize/unserialize methods is meant to hook into the
same-name functions.
That's a very technical and concrete thing - a behavior - not anything
abstract as an interface is.


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 serializabl=
e
>> thing".
>
>
> That's actually a very correct thing to do: by declaring that something i=
s
> `Serializable`, you are expressing your intent to anybody inspecting the
> structure of the object.
>

"intent" is the issue here: these is no such abstract thing here. The PHP
engine is a very concrete object that provides behaviors to userland. And
we need a proper hook to configure the behavior of the
serialize/unserialize functions. There is no such things as
interface/intent/abstraction here, just a hook and that's perfect because
the engine should define as little semantics as possible: that's the job of
userland!


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 dismissin=
g
> interfaces altogether (your current argument).
>

You completly ignored 1.: *any* object is serializable. Another hint there
isn't any abstraction sitting here: if Serializable was one, it would be
like a small wall in wide field.

The only way we could make "Serializable2" an abstraction is by fordbidding
any object that *does not* impementit to be serializable. That's
unrealistic - and uneeded to me.


> Serializability is something to be declared: currently, PHP is very much
> ill-designed on this particular scope, but that doesn't mean that we shou=
ld
> 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).
>

Please do, I'd be happy to better understand your pov.

It's yet another way to define something that would work correctly if an
> interface (existing mechanism defined by the language) was used instead.
>

It would not abstract anything, thus would be just broken syntactic
illusional sugar.

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 a=
n
> interface that works in combination with the `serialize()` and
> `unserialize()` functions.
>

"Language semantics" is another thing. I'm talking about "domain
semantics". See reasoning above :)

I'll also add that the problem being solved is much smaller than the issues
> introduced by the
>
proposed additions.
>

I promise the contrary: my personal experience is that Serializable does
real harm (please work on https://github.com/symfony/symfony/issues/29951
and related issues to get the feeling).
Magic methods would solve all this crap.

Cheers,
Nicolas

--0000000000000e9b5905808081e5--