Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107548
MIME-Version: 1.0
References: <CAF+90c-CaepNPOxOa937qCDwJ6c2XuQn0QKSk+-fH6wu9bSE1A@mail.gmail.com>
 <9668613b-5e9d-e67f-6001-3d360775eefe@gmail.com> <41aa6793-84da-ee39-8425-8a2240fd5b72@beccati.com>
In-Reply-To: <41aa6793-84da-ee39-8425-8a2240fd5b72@beccati.com>
Date: Mon, 14 Oct 2019 16:49:52 +0200
Message-ID: <CAF+90c8jUX+iRe_qb+FAN7+3Drb7KfcUFbVRJ5tkcDYupdKJXg@mail.gmail.com>
To: Matteo Beccati <php@beccati.com>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e677290594dffb0e"
Subject: Re: [PHP-DEV] Warning for "confusable" types
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000e677290594dffb0e
Content-Type: text/plain; charset="UTF-8"

On Mon, Oct 14, 2019 at 9:21 AM Matteo Beccati <php@beccati.com> wrote:

> Hi Stas,
> > Maybe we should just change the error message to this?> > must be an
> instance of the class "resource", but resource type is
> given> > OTOH, since there are actually no resource type hints, and
> naming your> class "resource" is an extremely bad idea, having a warning
> there> wouldn't hurt too.
> I was about to give my +1 on the more generic approach, but type hints
> could also be interfaces and "instance of the class X" is not a good fit.
>

We've tried to improve these error messages a couple of times already,
which is why it now say something like "an instance of resource, resource
given" rather than just "resource, resource given". This does help, but
there's a couple of disadvantages of trying to clarify the error message
when a type error occurs, rather than throwing a warning during compilation:

 * The error is introduced during the function declaration, because that's
where the incorrect type is used. Later errors will generally point to uses
of the function, which is not where the error lies in this case.
 * There are many different errors that can be triggered. There's argument
types, return types, property types, reference types, as well as things
like default values (something I saw recently: Someone being confused about
why "public double $foo = 1.5" throws an error.) All of these use different
error messages and it's something of a loosing battle to try and address
this issue in all of them.
 * Changing type errors is extremely costly, both as a one-time cost (test
updates) and in terms of maintenance. The current type errors we throw for
function arguments and returns are quite specialized, which makes it
unnecessarily hard to incorporate future type-system extensions. For
property types we went down a much simpler route of just printing the
canonical type name and not specializing anything, which would get ugly
pretty quickly, especially for reference errors that involve more than one
type.

This is why I think that this confusion needs to be addressed at the root,
when the type is actually used, not at some later point.

Nikita

--000000000000e677290594dffb0e--