Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77180
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.208 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <6f2236e18c61d30b247e1c6bb2de10f1@mail.gmail.com>
Date: Sun, 14 Sep 2014 15:54:03 +0100
Cc: Stas Malyshev <smalyshev@sugarcrm.com>,
 internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <807E0A88-3643-4EE0-B96E-B779903CF163@ajf.me>
References: <6893A97A-EC4C-4124-B804-96E2A26B953F@ajf.me> <20140914000718.GB14312@phcomp.co.uk> <3177B936-50C1-4E5D-8687-FD235C72B411@ajf.me> <54153692.7050500@sugarcrm.com> <9CE963B0-E624-4267-BC2A-0F8D1F985DAE@ajf.me> <6f2236e18c61d30b247e1c6bb2de10f1@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Subject: Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
From: ajf@ajf.me (Andrea Faulds)


On 14 Sep 2014, at 13:17, Zeev Suraski <zeev@zend.com> wrote:

> I honestly don't see why we can't be consistent for the simple types, =
or
> at least strive to be as consistent as possible as opposed to =
introducing
> a complete parallel universe for userland functions, that's =
inconsistent
> with the entirety of the rest of PHP.  We don't have to be consistent =
with
> ALL internal functions, which obviously have the option of doing =
custom
> checks and return failures not only if you fail to, say, pass on a =
string
> - but also if that string is not of a special format.  But then, you =
have
> the option of doing that also in userland functions using custom code.
> The question is not the customized cases - it's the standard =
behavioral
> cases - comparing zpp rules for scalars and the newly-introduced rules =
for
> userland scalars.

OK, we could go for exactly what zpp does already. However, then we =
don=92t have a compromise. We are siding with what you want, but most =
userland developers would prefer a strict system. While this would =
please you and perhaps some other folk on internals, and sure, it=92d be =
consistent, it would not be popular with the wider PHP community. =
Similarly, we could go for a fully strict approach, which might please =
some userland developers, but wouldn=92t please you.

I don=92t want to go down this route. I=92d prefer we compromise and =
keep PHP=92s weakly-typed nature (an int can be accepted as a float or a =
string), but make it stricter (no data loss), thus arriving at a middle =
way.

> We could definitely strive to be consistent;  Introduce some changes =
to
> the implicit casting rules for internal functions and implement the =
very
> same rules for this brand new userland functions.  I'm definitely =
against
> this RFC in its current form.

I wanted to do that, but it has its problems. I do not have the time to =
go through and update literally thousands of tests that would be broken =
by zpp changes. Also, any change to zpp=92s behaviour has backwards =
compatibility implications. There are some minor things I would like to =
change in zpp, which I will make an RFC for regardless of the success of =
this RFC (integer overflow should fail or at least raise a notice). =
Also, as I mentioned above, the resulting proposal would probably not =
please people who want strict types.

--
Andrea Faulds
http://ajf.me/