Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83352
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.214.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <052701d04d37$dd87d0f0$989772d0$@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>
	<052701d04d37$dd87d0f0$989772d0$@php.net>
Date: Fri, 20 Feb 2015 22:16:24 +0200
Message-ID: <CAPhkiZxwt+0f-6MO2GmDZzB7ahEOkhB0qUNUDK4bbDh8EKFrpw@mail.gmail.com>
To: francois@php.net
Cc: Levi Morrison <levim@php.net>, internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: [RFC] Reserving More Types in PHP 7
From: narf@devilix.net (Andrey Andreev)

Hi,

On Fri, Feb 20, 2015 at 8:05 PM, Fran=C3=A7ois Laupretre <francois@php.net>=
 wrote:
> 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 n=
eeds to be addressed first. I expect it to be clear for everyone that, as l=
ong as we share the same naming space between class/interface/trait names a=
nd type hinting keywords, each addition of a new keyword will be a real pro=
blem. So, we may reserve keywords in advance but it cannot be more than a w=
orkaround. 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 po=
tentially taken for existing or future classes, without any way to evaluate=
 the potential BC break, let alone the potential introduction of a third na=
ming space with a future 'typedef' feature ;). We see the case today with '=
resource' but that's just the beginning. What about 'mixed', 'scalar', or o=
thers I don't imagine yet ? The race to reserving keywords is lost in advan=
ce.
>
> Another point is that, thinking the reverse way, developers can legitimat=
ely 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 mec=
hanism 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_OB=
JECT', without conversion. Then the user who received it can distinguish wi=
th 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 ?
>

Sorry Fran=C3=A7ois, but I really didn't intend to go further into that top=
ic.

If Levi decides to add it as a second, optional vote - it's his
proposal and that's fine with me. I only expressed my opinon about
your suggestion to also reserve 'resource', because I don't have
voting karma and RFC discussion is my only way of influencing
decisions.

Cheers,
Andrey.