On Sun, Jan 27, 2019 at 5:37 PM Nicolas Grekas <nicolas.grekas+...@gmail.com> wrote:
> Le jeu. 24 janv. 2019 à 15:18, Sebastian Bergmann <sebast...@php.net> a > écrit : > > > 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/
