Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83334
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: "'Andrey Andreev'" <narf@devilix.net>
Cc: "'Levi Morrison'" <levim@php.net>,
	"'internals'" <internals@lists.php.net>
References: <CAFMT4No-KBHn6s5MqTV9CAQYHKCMWbiOnAwfPx8Xj=-x5++hHg@mail.gmail.com>	<CAFMT4NpTHMtfJuqO_RC6c8cv2Zg=JxFBC7pn6RHnrzqCON_r6Q@mail.gmail.com>	<04db01d04cc1$d9925770$8cb70650$@php.net> <CAPhkiZyH1erPE=Set9dOdtv=ikOB64u1NLnsn12dm5qPcxPOLQ@mail.gmail.com>
In-Reply-To: <CAPhkiZyH1erPE=Set9dOdtv=ikOB64u1NLnsn12dm5qPcxPOLQ@mail.gmail.com>
Date: Fri, 20 Feb 2015 19:05:51 +0100
Message-ID: <052701d04d37$dd87d0f0$989772d0$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQMXHS9CzopqIInM/HSYV4fHvuOWhAEbPl8VAb10GLUC6Es92Jo+GRZA
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 Andrey,

I think the question of reserving 'resource' or not is not the main one.

The question of having to reserve keywords is much more fundamental and =
needs to be addressed first. I expect it to be clear for everyone that, =
as long as we share the same naming space between class/interface/trait =
names and type hinting keywords, each addition of a new keyword will be =
a real problem. So, we may reserve keywords in advance but it cannot be =
more than a workaround. If we don't address the issue now, we'll end up =
with weird names for type hints, just because appropriate ones are *too =
appropriate* and potentially taken for existing or future classes, =
without any way to evaluate the potential BC break, let alone the =
potential introduction of a third naming space with a future 'typedef' =
feature ;). We see the case today with 'resource' but that's just the =
beginning. What about 'mixed', 'scalar', or others I don't imagine yet ? =
The race to reserving keywords is lost in advance.

Another point is that, thinking the reverse way, developers can =
legitimately ask why they cannot choose 'resource' as a class name, when =
the reason for this is a design mistake made when the 'array' type hint =
was introduced, or even before, when class hints were introduced without =
thinking the mechanism would be necessarily be extended.

Just a detail: I respectfully suggest anyone not to waste time to =
explain that the problem is solved by using lowercase-only keywords, at =
least not to me ;)

So, we need to propose a migration path towards a cleaner syntax. The =
STH RFC we are writing proposes one, keeping it as smooth as possible =
because the feature is heavily used.

Back to the particular case of 'resource': As the future of resources =
may be to be converted to objects while keeping the same API, the STH =
RFC will propose to define the 'resource' type hint as accepting =
'IS_RESOURCE|IS_OBJECT', without conversion. Then the user who received =
it can distinguish with is_resource/is_object() if needed.

So, 'resource' and 'resource|object' will be synonyms, while more =
precise users can use something like 'resource|object(GMP)'. All of =
these syntaxes will provide full BC when switching from resource to OO.

Thought ?

Regards

Fran=C3=A7ois