Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85987
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
Reply-To: <francois@php.net>
To: "'Stanislav Malyshev'" <smalyshev@gmail.com>,
	"'Nate Abele'" <nate.abele@gmail.com>,
	=?utf-8?Q?'Johannes_Schl=C3=BCter'?= <johannes@schlueters.de>
Cc: "'internals'" <internals@lists.php.net>
References: <EC598AEEF641411B949D685DF8262B4E@gmail.com> <CAFMT4Npcjz9kQjfSrKH3JwoyEUqCE6DzWnAaZ5c_idcuVAQ2fA@mail.gmail.com> <A326B86EEE4C4E36B85455E01F355A22@gmail.com> <553DBEC4.7000609@gmail.com>
In-Reply-To: <553DBEC4.7000609@gmail.com>
Date: Tue, 28 Apr 2015 13:32:48 +0200
Message-ID: <006c01d081a7$0e600640$2b2012c0$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQJH4NXmYqiUFTwX4N+eJK7dHOGqJgGFwxK9AWEuISgCX5oKXpxJRlng
Content-Language: fr
Subject: RE: [PHP-DEV] Re: [RFC] Reserving More Types in PHP 7
From: francois@php.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=)

Hi,

> De : Stanislav Malyshev [mailto:smalyshev@gmail.com]
>
> There was a lot of discussion about this topic. Right now, unless
> there's a proposal to fix it that works, I don't see what can be done
> about it.

I wrote a long message some months ago to explain why reserving names =
was, IMHO, the wrong way to go =
(https://www.mail-archive.com/internals@lists.php.net/msg75672.html). =
The problem comes from authorizing bare class names as type hints. =
That=E2=80=99s history, none to blame here, it should just have been =
solved when type hints were extended to arrays, but, with the extension =
to scalars, it is now urgent.

Solving conflicts one by one, and discussing whether 'String' is a bad =
choice for a class name, or if it should be reserved in a case-sensitive =
way, won't solve anything. 'String' is just the first one to jump in. =
Consider 'Resource', 'Object'... All potential endless discussions to =
clutter the mailing list and make users afraid of switching to 7. =
Potential result : the old circle Johannes is talking about and the =
python 2/3 effect.

I think we need to consider we have a name conflict, as we are using the =
same name space for two different concepts, and decide a long-term =
strategy to address it, preferably before releasing 7.0. Once again, I =
propose what I still consider as the only long-term solution proposed so =
far : slowly, step by step, deprecate the usage of bare class names as =
type hints. It looks like a huge break, and it is, but we can make it =
smooth. Here are the steps I have in mind :

- In 7.0, introduce the 'object' (accepts any object instance) and =
'object(ClassName)' (similar to the bare 'ClassName') type hint =
syntaxes. Bare class names are still recognized and priority is given to =
class names (if a 'String' class is defined, every 'String' or even =
'string' type hints will always refer to it). So, compatibility is =
preserved, even if class names conflict with scalar type hints. =
Prominent frameworks will easily change their 'String' type hints to =
'object(String)' and be prepared for the next step. Anyway, they have =
several years to do it and the most important is that they keep their =
class names.

- In a second step, probably in 8.0, and with a prior deprecation =
message introduced in a 7.x version to define, remove support for bare =
class names as type hints. This step can be refined later. The most =
important is to introduce the target syntax as soon as possible.

Regards

Fran=C3=A7ois