Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115747
Message-ID: <556F04FF-B1FE-4BBE-877E-7C52D5EB6A35@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_CE3B5758-CB90-4775-817B-3E7DD518529E"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Date: Sun, 15 Aug 2021 22:29:47 -0400
In-Reply-To: <CAAwdEzABa_ohA6Pwsx+_++askje5NLOSNPH+Y8Txz_TQtPmWAQ@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
To: =?utf-8?Q?Alexandru_P=C4=83tr=C4=83nescu?= <drealecs@gmail.com>,
 Jordan LeDoux <jordan.ledoux@gmail.com>
References: <CAMrTa2HYeKaE9E+A81HvSykpAD8ctd6aK9vtg_U15bYjyjzLKA@mail.gmail.com>
 <CAAwdEzABa_ohA6Pwsx+_++askje5NLOSNPH+Y8Txz_TQtPmWAQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Never For Argument Types
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_CE3B5758-CB90-4775-817B-3E7DD518529E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Aug 15, 2021, at 7:06 PM, Alexandru P=C4=83tr=C4=83nescu =
<drealecs@gmail.com> wrote:
>=20
> If I see an interface that was created just so it can be implemented =
by
> multiple classes but the caller doesn't use the interface but it uses =
the
> actual classes, I call it out as that is the wrong abstraction and the
> interface should just be removed.
>=20
> Your example with ArrayAccess is similar with this; when using it, you =
know
> exactly what implementation you have. The interface is not helping =
here
> related to polymorphism but it is actually required to allow a =
language
> construct related to the engine itself, to translate accessing an =
object
> with the same syntax as for an array.
>=20
> If the 4 functions would have been magic methods, without an =
interface, you
> would not have this problem.

That is very insightful.=20

It seems that back when PHP only had a hammer, PHP used a hammer. But =
now that PHP has a better tool for the job maybe PHP should change =
course?

More specifically, since ArrayAccess is primarily being used as a class =
annotation and not to enable polymorphism maybe the best course of =
action would be to deprecate having `ArrayAccess` the interface being an =
annotation and to instead having `#[ArrayAccess]` the attribute tell PHP =
to allow indexing instances of the class like an array?


> On Aug 15, 2021, at 6:22 AM, Jordan LeDoux <jordan.ledoux@gmail.com> =
wrote:
>=20
> 2. Interfaces have more purposes than just standing in for classes in =
a
> type hint. Interfaces also guarantee an implementation.

Correct.  Which is why interfaces that allow for non-specific types =E2=80=
=94 e.g. `mixed` or `never` =E2=80=94 weaken that guarantee[1].

If `never`-parameter interfaces were to exist then code that passes a =
parameter to a `never`-parameter method would first have to check via =
reflection if the type if wants to pass will be accepted. That nullifies =
the guarantees of an interface.

I think the reason for envisioning `never` as an option to address the =
concerns it attempts to address is the unfortunately ramification of, as =
Alex identified, the choice to use an interface as a signal to provide =
language specific behavior to a class rather than to enforce polymorphic =
behavior.=20

So rather than double down on features based on leaky abstractions =
better to backtrack and correct the original sin IMO.

-Mike


--Apple-Mail=_CE3B5758-CB90-4775-817B-3E7DD518529E--