Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86342
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1728446955.140561.1432207869694.JavaMail.root@zimbra71-e12.priv.proxad.net>
References: <CAF+90c8ap8eEt0Bj1jY89AxS58QQ8ExTGGoR-zkRnJgg72UOMQ@mail.gmail.com>
	<1728446955.140561.1432207869694.JavaMail.root@zimbra71-e12.priv.proxad.net>
Date: Thu, 21 May 2015 19:46:13 +0700
Message-ID: <CAEZPtU7rABqs=EB-aX_VRgFtjYdtGSy2QArgxdkXO8z0ndjLSg@mail.gmail.com>
To: flaupretre@free.fr
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1139594ec5ef45051696ed9b
Subject: Re: [PHP-DEV] Soft-reserve "void" class name
From: pierre.php@gmail.com (Pierre Joye)

--001a1139594ec5ef45051696ed9b
Content-Type: text/plain; charset=UTF-8

On May 21, 2015 6:45 PM, <flaupretre@free.fr> wrote:
>
> Hi,
>
> > De: "Nikita Popov" <nikita.ppv@gmail.com>
> >
> > For PHP 7 we soft-reserved a number of class names [1] like "numeric",
so
> > that we have the ability to introduce them as typehints in a 7.x
release.
> > "Soft" here means that we only document these names as being reserved
and
> > don't throw an error when they're used.
> >
> > I'd like to add "void" to this list, so we have the option to introduce
a
> > void return type in PHP 7.x. I've seen some disagreement as to whether
this
> > should be called "void" or "null" - this discussion should be held when
an
> > RFC comes up, however we need to keep both options open until then.
> > (Currently only "null" is reserved.)
>
> May I repeat my arguments to have this reservations enforced by a warning
message ? 'Soft' reservation
> is easier but it is not enough. If we give a special meaning to one of
these names in a 7.x release,
> we will introduce a BC break, whatever the documentation states, because
that's the definition of a BC
> break : software that works fine in 7.0 and does not work the same in
7.x. Do we want to guarantee BC on
> minor versions ? If we don't enforce a check on reserved class names,
IMO, we can't. Once again, this is
> a short-term half-baked solution we'll pay later.
>
> PS: If you're OK, I am ready to implement the check.

Also I am fine to reserve it, I am not in favor of doing any time in 7.x.
If it means to do it now, then let do it now.

Cheers,
Pierre

--001a1139594ec5ef45051696ed9b--