Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88781
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <561D0D81.2020306@gmail.com>
References: <5C.21.16518.AA80C165@pb1.pair.com>
	<561CDFFA.8040207@php.net>
	<E6.A2.04042.064EC165@pb1.pair.com>
	<561D0D81.2020306@gmail.com>
Date: Tue, 13 Oct 2015 11:40:45 -0400
Message-ID: <CAAyV7nF1hZ7v0f_Yo0_ZCdEJs6_RGUC6uuY6ocdD61Z_rOo6fw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Scalar type hints and scalar type name aliases causeconfuson
From: ircmaxell@gmail.com (Anthony Ferrara)

All,

On Tue, Oct 13, 2015 at 9:56 AM, Rowan Collins <rowan.collins@gmail.com> wrote:
> Andrea Faulds wrote on 13/10/2015 12:00:
>>
>> Hi Michael,
>>
>> Michael Wallner wrote:
>>>
>>> On 12/10/15 21:23, Andrea Faulds wrote:
>>>>
>>>> Even if we can't reserve the names, I hope we can do the two other
>>>> suggestions in time for release.
>>>
>>>
>>> Additionally, we could say "instance of class ...".
>>>
>>
>> We could do that, though it's already 'instance of'. Not sure on this one.
>
>
>
> It's not necessarily a class you're requiring an instance of, it could (and
> according to some design disciplines "should") be an interface. I think the
> "did you mean..." is more useful if we don't make everything alias.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>


I think it's important to clean up these error messages and make it
easier to find the root problem.

With that said, I strongly believe that adding new reserved classes is
the wrong way to do that. Part of the problem is inconsistency around
what we call types in the first place. This leads to confusion around
what types people expect and how they expect them.

An example is the fact that types are different all over the place.
Cast tokens, the return of gettype(), documentation, etc.

Everything is inconsistent. And reserving extra types because of this
inconsistency does nothing to actually fix the problem.

Instead, my suggestion would be to double-down on clarifying that
"int"/"float"/"bool"/etc are the canonical correct versions, and
everything else is an alias. In future versions (likely 8, but
possibly earlier) we could deprecate the aliases, to keep things far
more consistent.

Reserving more classes now (both 7.0 and this late in the RC process)
is IMHO not a great idea. Either side sucks (whichever we do we're
wrong), but at least not reserving gives us a path towards cleaning it
up rather than making it worse.

I like Derick's suggestion (though removing "class"):

Fatal error: Uncaught TypeError: Return value of foo() must be an
instance of boolean, scalar boolean returned

The "instance" says it's an object.

The rest of it becomes a documentation problem. We're already mostly
consistent in the docs (all of the signatures use the correct tokens),
so it shouldn't be hard to finish that off...

My $0.02 at least.

Anthony