Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82925
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.223.172 as permitted sender)
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>
MIME-Version: 1.0
Thread-index: AQGD0sLDaA+/0NIeBlQhQC5OtPA/xwHih9+6AanvcsEBj7eMC51kYKqA
Date: Tue, 17 Feb 2015 08:04:10 +0200
Message-ID: <d8031ce52e9965c789887e8f7b687a4e@mail.gmail.com>
To: Sara Golemon <pollita@php.net>, francois@php.net
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PHP-DEV] Reviving scalar type hints
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: php@golemon.com [mailto:php@golemon.com] On Behalf Of Sara
> Golemon
> Sent: Tuesday, February 17, 2015 1:58 AM
> To: francois@php.net
> Cc: Philip Sturgeon; Arvids Godjuks; Jefferson Gonzalez; Rowan Collins;
> PHP
> internals
> Subject: Re: [PHP-DEV] Reviving scalar type hints
>
> On Mon, Feb 16, 2015 at 2:50 PM, Fran=C3=A7ois Laupretre <francois@php.ne=
t>
> wrote:
> > Once again, anyone can take over version 0.3, if it is so great. Why
> > don't
> you do it ?
> > I will play the game, stop working on my proposal, and vote 'yes' again=
.
> > But don't ask me to do it in your place.
> >
> If nobody else does it, I will.
>
> 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.
>
> Straw poll:
> 1) <?php strict;

I like this one best.  Obviously it requires some extra definition (e.g. I
assume it will only be possible at the first block, perhaps only as the
first part of the file or such).

That syntax poll aside, I had what I hope is some sort an enlightenment, an=
d
I think I know what will get me to cast my vote in favor of 'strict', as a
true supporter.  There's one very special conversion that's too common in
PHP to dismiss (IMHO), and is also completely harmless in 99.999% of the
cases, if not strictly 100%:

string->int or string->float conversions, when the string looks *exactly*
like a number.  Given almost all of our inputs (from databases, forms,
files, etc.) come in string form, that's by far the conversion that's going
to give us the most trouble - and is most probably the use case that by far
is going to result the largest amount of explicit casts to work around that
problem.

What if strict mode didn't just blindly check zval.type, but actually
allowed for this one type of conversion to go through without a problem?

No bool to int.  No Apple to int.  No "123 testing" to float.  Just "32" to
32 and "37.7" to 37.7.

Can the strict supporting camp consider that option?  Judging by the
examples brought up by proponents of v0.3, this type of conversion isn't
their issue.  It's the 'obviously wrong' conversions that bug them.

As a secondary concern I'd put int to float conversions where no
(meaningful) data is being lost, e.g. 37 -> 37.0, even though a tiny bit of
accuracy is lost.  Rejecting this particular conversion places us at being
stricter than mostly all other languages.  That said, it's a much less
common conversion so I don't feel nearly as strongly about it as the string
one.

Last, regarding internal functions, I do agree with Rasmus and Drew.  Again=
,
judging by the examples brought up  as a part of the discussion, it seems a=
s
if we gave ZPP developers a standard easy way of being a lot more picky
about the types of values of particular arguments, and allowing them to do
this selectively for those places that are very sensitive (e.g.
curl_setopt()) would be a more suitable solution than just turning strict
validation for all internal functions, which were built with very very
different assumptions in mind.  The biggest difference between internal
functions and userland functions in the context of this RFC is that with
userland functions, we're starting with a clean slate.  There are no type
hint definitions anywhere, developers can selectively add them as they see
fit.  With internal functions, we have type requirements EVERYWHERE already=
,
but with semantics that didn't take strict typing into account at all and
evolved for almost 20 years.  Strict typing the way it is now would
radically change these semantics overnight, and will make the adoption of
strict a much bigger headache than it can be, as I believe Rasmus
demonstrated.

I think addressing these issues could get us a LOT closer to consensus and
make a lot of those who voted 'no' on v0.3 vote yes  on v0.4.

Thanks for your consideration.

Zeev