Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88789
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Andrea Faulds'" <ajf@ajf.me>,
	<internals@lists.php.net>
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> <CA+9eiLv-pxtU==yprfNYEMTUUdT03Phyw+k5+vvcA15Dzycksg@mail.gmail.com> <11.E0.41961.54B8D165@pb1.pair.com>
In-Reply-To: <11.E0.41961.54B8D165@pb1.pair.com>
Date: Wed, 14 Oct 2015 11:57:32 +0200
Message-ID: <000001d10666$c6008a10$52019e30$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQK797VAxFKxjcRxTuBG4IvM/F443AN6I4HRAb4iQ1wBGDvCzAG8BQPfAlhES+sCqDlv0pwsb+aQ
Content-Language: en-us
Subject: RE: [PHP-DEV] Scalar type hints and scalar type name aliases causeconfuson
From: anatol.php@belski.net ("Anatol Belski")

Hi Andrea,

> -----Original Message-----
> From: Andrea Faulds [mailto:ajf@ajf.me]
> Sent: Wednesday, October 14, 2015 12:53 AM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Scalar type hints and scalar type name aliases
> causeconfuson
>=20
> Hi Dmitry,
>=20
> Dmitry Stogov wrote:
> >
> > 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.
> >
>=20
> Just changing error messages would work, but it's an unclean solution.
> It would be changing existing naming conventions ('integer' in =
English, 'int' in
> code). Still, it's better than nothing if we can't reserve the names.
>=20
People already ported a lot of stuff to 7.0, or get already trained, =
etc. So changing the error message looks like the only how far we can go =
at current stage. It is clear enough to express the necessary error, and =
it is soft enough to will possibly break some unit tests but not the =
actual codes.

Thanks

Anatol