Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83402
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <059701d04d73$bf9a4280$3ecec780$@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>
	<d8031ce52e9965c789887e8f7b687a4e@mail.gmail.com>
	<CAESVnVpA+M6iv_zbDmKTEF8Q1zKjwnbi1ucc=UyuUyRr+X+U3w@mail.gmail.com>
	<022801d04ab1$4a0c47d0$de24d770$@php.net>
	<1913e09d7f52541901d8574d2080a63f@mail.gmail.com>
	<CAAyV7nFD=BQ5dBYiKzhbOKTomKmWvruTnb=R_n9mYB-Lz1P9pg@mail.gmail.com>
	<7a5d96b34b98ec1f3ee17be7fa6a1e81@mail.gmail.com>
	<CAPhkiZxpYbaPN1370_HFTVnBA=Jg-rU8DrB2P+2dmRcJfGWPtw@mail.gmail.com>
	<2CBDEB67-3DE3-437D-9AF3-0E6A92027244@zend.com>
	<CAPhkiZwcD3h42=9eak4uP9n2GBE=v0LVP6Ncq9Oz7L91dJ5y5w@mail.gmail.com>
	<4cc0c81c7199a452534bb8edcdb19914@mail.gmail.com>
	<54E589F6.9030002@garfieldtech.com>
	<d62afd01c97a2d00466ac88579fa861c@mail.gmail.com>
	<54E66569.8000709@garfieldtech.com>
	<CAAyV7nG79GbQt_hcAsV15Ad-7k7KjDW43HTGyegHPoswDMNzJA@mail.gmail.com>
	<059701d04d73$bf9a4280$3ecec780$@php.net>
Date: Sat, 21 Feb 2015 11:21:08 -0500
Message-ID: <CAAyV7nHTR7iKN_Tyq31vKg7U6pW5=XYjT=hsz9PSy2iKtWo3_A@mail.gmail.com>
To: francois@php.net
Cc: "internals@lists.php.net" <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: ircmaxell@gmail.com (Anthony Ferrara)

Francois,

> Adding this case to 'float' meaning 'int|float' and 'callable' resolving =
to 'string|array|object', are you sure it's worth the pain implementing and=
 supporting a dual-mode mechanism, compared to the ruleset I am intending t=
o propose (currently in draft): https://wiki.php.net/rfc/zpp-conversion-rul=
es ?

I've taken a look at that proposal, and here are my comments:

1. This RFC only talks about ZPP. I assume you're also talking about
exposing the same ruleset to userland?

2. You're talking about making passing `1` to a bool parameter
disallowed by default. Meaning that a **LOT** of code will break
automatically when upgrading to 7. Because internal function's error
behavior will change.

This **will** likely create a python 2/3 situation here. You're making
a MASSIVE bc break here.

If you were just talking about user-land types, that would be one
thing. But since you're explicitly talking about ZPP, this is a bad
thing.

3. It still doesn't solve the problems the strict type proponents are
looking to have solved (namely that the type is what's checked, not
the value). The is_numeric_string cleanup is definitely a step in the
right direction (and I think should be implemented anyway), but it
still doesn't solve the problem.

Overall, this proposal feels like a compromise in a bad way. It makes
existing code error (bc break), doesn't give the weak proponents what
they want and doesn't give the strict proponents what they want
either. Just because it's the middle ground doesn't make it a good
thing.

Please consider these issues seriously prior to making the proposal officia=
l.

Anthony