On Mon, Oct 14, 2019 at 9:21 AM Matteo Beccati <p...@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
