Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85992
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: "'Rowan Collins'" <rowan.collins@gmail.com>,
	<internals@lists.php.net>,
	"Stanislav Malyshev" <smalyshev@gmail.com>,
	"Nate Abele" <nate.abele@gmail.com>
References: <EC598AEEF641411B949D685DF8262B4E@gmail.com> <CAFMT4Npcjz9kQjfSrKH3JwoyEUqCE6DzWnAaZ5c_idcuVAQ2fA@mail.gmail.com> <A326B86EEE4C4E36B85455E01F355A22@gmail.com> <553DBEC4.7000609@gmail.com> <006c01d081a7$0e600640$2b2012c0$@php.net> <553F7818.1040402@gmail.com>
In-Reply-To: <553F7818.1040402@gmail.com>
Date: Tue, 28 Apr 2015 15:35:38 +0200
Message-ID: <007601d081b8$36b9b490$a42d1db0$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQJH4NXmYqiUFTwX4N+eJK7dHOGqJgGFwxK9AWEuISgCX5oKXgGIIOFyAnR+IiqcKYUvMA==
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?=)

> De : Rowan Collins [mailto:rowan.collins@gmail.com]
>=20
> This part is likely to be rather tricky to implement. How do you know =
if
> a 'String' class is defined or not?
>=20
> The Engine would have to do something like this:
>=20
> - check in-scope use statements for resolutions of 'String' to a
> qualified name
> - if in namespace scope, try class_exists(__NAMESPACE__ '\String'),
> invoking autoloader if registered
> - if not in namespace scope, check class_exists('String'), invoking
> autoloader if registered
> - if class found, hint is an object instanceOf check
> - else, hint is a scalar check
>=20
> All of this (apart from resolving use statements) has to run *every =
time
> the hint is processed*, since there is no limit on when a class can
> become defined. The user has no way of avoiding this penalty, even if
> they never intend to declare a String class.

That's right. The transitional phase would introduce a small performance =
penalty. But that's temporary : as soon as we remove support for bare =
class names, the runtime overhead and complexity disappears.

A simpler, but still acceptable solution, would be just to introduce the =
'object' and 'object(Classname)' syntax. Then, we still consider that =
'string' is reserved, the compiler recognizes it as a scalar hint, and =
we tell programmers they must switch their type hints to the new syntax =
when they conflict with a reserved name. Actually, the message would be =
that, because of potential conflicts, bare class names are still =
supported but discouraged and deprecated soon, whatever the class name. =
We lose the full BC but it may be acceptable for a major version. Then, =
it can be deprecated in 7.x and suppressed in 8.0. A side effect is that =
we don't have to reserve names anymore, which will avoid a lot of =
endless and sterile discussion. It would be simple and quick for =
prominent frameworks and software to switch to the new syntax, the most =
important being that they don't have to modify their class names. We can =
even backport the 'object(classname)' syntax to PHP 5 to make the =
migration path smoother.

If we accept it can still target 7.0, I propose to write an RFC just =
proposing to add this syntax.

I am sorry to insist but we really need to do something. Just look at =
the suggestion of considering 'string' as the only case-sensitive class =
name. Are you ready to discuss more and more silly workaround =
suggestions like this one ? While I am all for making class names =
case-sensitive (off-topic), distinguishing 'String' from 'string' is =
definitely a very bad reason ;).

I am especially interested by the opinion of Drupal, Wordpress, and =
other framework developers. Are there any out there ? Please comment.

Regards

Fran=C3=A7ois