Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115759
MIME-Version: 1.0
References: <CAMrTa2HYeKaE9E+A81HvSykpAD8ctd6aK9vtg_U15bYjyjzLKA@mail.gmail.com>
 <CAF+90c9_GMyyMfSFGsELaEbi5-Cbcx68ae8OkUpE8WuEm46m_w@mail.gmail.com>
 <CAMrTa2GGrmmHFM+_K63gfxdLEEWdiotHQbXm1VmUK1fi4AC-kg@mail.gmail.com> <CAF+90c-Z+n16s=_bBgaLpsXEGknCYv9tN2Xk1bvUs563RMp3_A@mail.gmail.com>
In-Reply-To: <CAF+90c-Z+n16s=_bBgaLpsXEGknCYv9tN2Xk1bvUs563RMp3_A@mail.gmail.com>
Date: Mon, 16 Aug 2021 07:59:39 -0700
Message-ID: <CAMrTa2E6Hk3eAbUAaZiPqgE-7-YHBfVe8ibP6xbhXJxNwhpvAw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b016df05c9ae7340"
Subject: Re: [PHP-DEV] [RFC] Never For Argument Types
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000b016df05c9ae7340
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 16, 2021 at 12:51 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

> We have a better way to specify markers for the engine: Magic methods. I
> think some people have a mistaken notion that engine-integrated interfaces
> are always better than magic methods. This is only the case if such
> interfaces are actually useful from a type system perspective. For example,
> Countable and Traversable are useful magic interfaces, because you can
> sensibly type against them. The recently introduced Stringable interface
> (for the magic method __toString) falls in the same category.
>
> Conversely, Serializable is actively harmful as a magic interface (apart
> from the other issues with it), because whether an class implements
> Serializable does not determine whether it is serializable -- all objects
> are a priori serializable, the Serializable interface just gives it custom
> serialization behavior. You'll note that the new __serialize/__unserialize
> methods are plain magic methods without an interface. With exception of a
> custom serializer implementation, user code should never be checking for
> Serializable.
>
>
What would be your thoughts for the case of ArrayAccess? The engine
integration can't really be used without multiple methods being
implemented, so some form of contractual implementation does make sense.
Additionally, the interface does provide some useful typing features, such
as ArrayAccess|array. However the interface itself doesn't guarantee much
about the actual implementation while being a prime candidate for something
like the never type proposed here. In the case of ArrayAccess, it sort of
exists to provide operator overloading for []. But I don't think it'll be
the last time that we encounter an engine feature that is best provided
through multiple method implementations.


> The operator overloading case is in between: The interface is not actively
> harmful, but they also aren't useful. Given the lack of generics, it's not
> really possible to write code against a "Multiplyable" interface that
> actually provides a useful guarantee. The interface does not distinguish
> whether "T * T" is valid, or only scalar multiplication "T * float" is
> supported. When working with operator overloads in PHP, I expect usage to
> type against a specific class implementing operator overloading, say Money,
> rather than typing against something like Addable&Multiplyable. The latter
> would accept both Money and Matrix, both of which have entirely different
> rules on the kinds of operands they accept, even if they are, in some
> sense, addable and multiplyable.
>
> Regards,
> Nikita
>

To be honest, I don't imagine there are many cases where the __add() method
would use the Addable interface (assuming it existed) as a way to type the
second operand. That would only guarantee that the *other* operand could
handle the adding if it had to, but doesn't tell the called method anything
about how to access the value that the object represents which needs to be
added. I think it is far more likely that it'll be typed against specific
classes, like you're suggesting, in almost all uses of the feature. If for
no other reason than simply the fact that different values mean different
things to different objects.

Perhaps it would lead to a community standard around types of values that
*should* be interoperable, something like a Numberlike interface, but I
have purposely avoided venturing into that so far in my draft of that RFC
because it seemed too opinionated to me, and I wanted to avoid getting into
the domain-specific implementations that some were suggesting. That could
easily spiral into a multitude of very specific implementations ending up
in core, when they more naturally belong in the context aware user space of
the application they are used in.

I am open to suggestions on alternatives. I will also be thinking about a
form this might take that would address this concern while still providing
a cleaner way for engine-like object shapes to be typed. I feel like this
is one of the less disruptive ways that could be done, but less disruptive
obviously means that it will inherit any lingering issues that may exist in
that area.

Jordan

--000000000000b016df05c9ae7340--