Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84074
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: "'Brian Moon'" <brian@moonspot.net>,
	"'Benjamin Eberlei'" <kontakt@beberlei.de>,
	"'Zeev Suraski'" <zeev@zend.com>
Cc: "'PHP internals'" <internals@lists.php.net>
References: <d238d736f8fcde9e649cb38c9b05fcc1@mail.gmail.com> <CAEPJduntsR-Z9EtrjuN49Po0ctOrdnpga2hC18qQy2k6q_c8rw@mail.gmail.com> <54F0A9C1.6050904@moonspot.net>
In-Reply-To: <54F0A9C1.6050904@moonspot.net>
Date: Sat, 28 Feb 2015 09:40:25 +0100
Message-ID: <0bc701d05332$32fee460$98fcad20$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQHbEgvqZ08kgCvmYfG4mXODzCFejgJSRgVdAbuTZOWcz82Y4A==
Content-Language: fr
Subject: RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC
From: francois@php.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=)

> De : Brian Moon [mailto:brian@moonspot.net]
>
> I agree here with Benjamin. The thing I have wanted in user land for
> years is to be able to build a user land function that worked the way
> internal functions do in terms of type checking without having to =
build
> my own type checking system. Having internal functions convert null to =
a
> scalar and not having user land do the same creates an inconsistency.
> For example, sometimes you want to wrap/extend an internal function =
(you
> see it a lot with json* to do encoding checking). I can't reliably =
take
> the same input to my user land wrapper that I can send to the internal
> function. I would prefer to see the same rules apply to internal and
> user land.

It would be better, yes. Unfortunately, accepting or refusing null to =
scalar in both is difficult. If we disable null to scalar, we =
potentially generate a lot of deprecation messages for existing code  =
calling internal functions this way. If we enable null to scalar, we =
create massive future inconsistencies now and in the future. An example =
:

Function foo(): string {} // OK because returns null and null accepted =
as string.

My opinion, but that's only mine, is that I would favor deprecating null =
to scalar, even for internal functions. It would add deprecation =
messages but we'd end up with a cleaner code.

Regards

Fran=C3=A7ois