Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82911
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain lerdorf.com designates 209.85.220.43 as permitted sender)
Message-ID: <54E290E5.3020508@lerdorf.com>
Date: Mon, 16 Feb 2015 16:52:53 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Sara Golemon <pollita@php.net>, francois@php.net
CC: Philip Sturgeon <pjsturgeon@gmail.com>, 
 Arvids Godjuks <arvids.godjuks@gmail.com>,
 Jefferson Gonzalez <jgmdev@gmail.com>, 
 Rowan Collins <rowan.collins@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <011801d04a07$83ab1c00$8b015400$@php.net>	<CABDNdAFQsbo-A-gijPCwYDOf3ts-yKpP0tAL--WUaLU26GB-AQ@mail.gmail.com>	<016f01d04a3a$e9183220$bb489660$@php.net> <CAESVnVoM7YbmXA8hTG1O66j+6YX3Xx2Q3uj_F=TPjHA4ws=8JA@mail.gmail.com>
In-Reply-To: <CAESVnVoM7YbmXA8hTG1O66j+6YX3Xx2Q3uj_F=TPjHA4ws=8JA@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="nfGbsQ6hkHOtcJQCf5iS1BcWfjHJeLIQk"
Subject: Re: [PHP-DEV] Reviving scalar type hints
From: rasmus@lerdorf.com (Rasmus Lerdorf)

--nfGbsQ6hkHOtcJQCf5iS1BcWfjHJeLIQk
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 02/16/2015 03:58 PM, Sara Golemon wrote:
> On Mon, Feb 16, 2015 at 2:50 PM, Fran=C3=A7ois Laupretre <francois@php.=
net> wrote:
>> Once again, anyone can take over version 0.3, if it is so great. Why d=
on't you do it ?
>> I will play the game, stop working on my proposal, and vote 'yes' agai=
n.
>> But don't ask me to do it in your place.
>>
> If nobody else does it, I will.
>=20
> I think Andrea's 0.3 proposal was extremely well balanced, served
> everyone's needs whether they would admit it or not, and who's only
> failing (subjectively termed) was the use of declare().  I think
> declare() is fine and not nearly as ugly as some have slandered it to
> be, but I'm willing to read the winds and modify it for v0.4.

I still disagree strongly that it serves everyone's needs. The internal
API and APIs provided by extensions are completely messed up by this
approach. Userspace authors get the choice when they write their code.
Even if the caller has turned on strict, if you haven't added strict
types to your functions/methods you are fine. Internal API and extension
authors don't get this luxury. If the caller turns on strict, then
suddenly an API that was written explicitly to make use of the coercive
characteristics PHP has had for 20+ years breaks and there is nothing I
can do about it as an extension author. This is beyond just int->float
coercion, which is, of course, also missing.

A simple example:

number_format($num);

So, for various inputs without strict enabled:

int(1000)
1,000

string(4) "1000"
1,000

float(1000)
1,000

string(5) "1000 "
Notice: A non well formed numeric value encountered in ...
1,000

string(5) " 1000"
1,000

string(9) "1000 dogs"
Notice: A non well formed numeric value encountered in ...
1,000

string(3) "dog"
Warning: number_format() expects parameter 1 to be float, string given
NULL

resource(5) of type (stream)
Warning: number_format() expects parameter 1 to be float, resource given
NULL

This is the intended API. The function does some sanity checking for
things that clearly don't make sense based on what it was written to do
and fails hard. It also lets the user know about questionable data and
relies on coercion for the rest. You could argue that the "1000 dogs"
case should be more severe than a notice, but that is pretty minor I
think. The extension author has the ability to make that more severe if
she likes.


Now turn on strict and we get:

int(1000)
number_format() expects parameter 1 to be float, integer given

string(4) "1000"
number_format() expects parameter 1 to be float, string given

float(1000)
1,000

string(5) "1000 "
number_format() expects parameter 1 to be float, string given

string(5) " 1000"
number_format() expects parameter 1 to be float, string given

string(9) "1000 dogs"
number_format() expects parameter 1 to be float, string given

string(3) "dog"
number_format() expects parameter 1 to be float, string given

resource(5) of type (stream)
number_format() expects parameter 1 to be float, resource given

That in itself might not be so terrible, but also not terribly useful
and it is nothing like what the extension author had intended. And how
do you think users will deal with internal functions that are now
suddenly strongly typed even though they were not designed to be? Do you
think they will go look at the source code for the function and mimic
the data sanity checks and put those in their userspace code? Doubtful,
and as people on irc and everywhere have told me, they will just cast.
No big deal. So, we run the same set of data through with strict enabled
and doing a number_format((float)$num):

int(1000)
1,000

string(4) "1000"
1,000

float(1000)
1,000

string(5) "1000 "
1,000

string(5) " 1000"
1,000

string(9) "1000 dogs"
1,000

string(3) "dog"
0

resource(5) of type (stream)
5


Out of the 3 scenarios, this is inarguably the worst outcome with the
last line there being the most blatant. Actually outputting an internal
resource id as if it was a valid number to be formatted without the
slightest notice or warning anywhere that something is wrong in the code.=


This is my fear with this approach. People will start littering their
code with casts and it will hide real bugs which is the complete
opposite of what motivated this in the first place.

Without more thought into how we properly deal with internal/extension
code I don't really understand how so many people foresee this to work
perfectly in the real world.

-Rasmus


--nfGbsQ6hkHOtcJQCf5iS1BcWfjHJeLIQk
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlTikOUACgkQlxayKTuqOuD8jQCgioS17uX3AAdUuPA2STcRdAF1
do4AmgJYIGOsYkRVkcFL3YC79Q589nEi
=L4r+
-----END PGP SIGNATURE-----

--nfGbsQ6hkHOtcJQCf5iS1BcWfjHJeLIQk--