Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88784
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.213.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nF1hZ7v0f_Yo0_ZCdEJs6_RGUC6uuY6ocdD61Z_rOo6fw@mail.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>
	<CAAyV7nF1hZ7v0f_Yo0_ZCdEJs6_RGUC6uuY6ocdD61Z_rOo6fw@mail.gmail.com>
Date: Tue, 13 Oct 2015 23:16:07 +0300
Message-ID: <CA+9eiLv-pxtU==yprfNYEMTUUdT03Phyw+k5+vvcA15Dzycksg@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: Rowan Collins <rowan.collins@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01538ca0c399f70522021de6
Subject: Re: [PHP-DEV] Scalar type hints and scalar type name aliases causeconfuson
From: dmitry@zend.com (Dmitry Stogov)

--089e01538ca0c399f70522021de6
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 13, 2015 at 6:40 PM, Anthony Ferrara <ircmaxell@gmail.com>
wrote:

> 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
>

I also don't like reserving new class names or limiting their use.
The message above looks clear and it shouldn't be a big problem to
implement the fix.
This fix shouldn't change anything except error message, so it'll make
minimal risk for 7.0 release process.

Thanks. Dmitry.


>
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--089e01538ca0c399f70522021de6--