Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77198
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender)
Date: Sun, 14 Sep 2014 21:22:27 +0100 (BST)
To: Andrea Faulds <ajf@ajf.me>
cc: Zeev Suraski <zeev@zend.com>, Stas Malyshev <smalyshev@sugarcrm.com>, 
    PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <807E0A88-3643-4EE0-B96E-B779903CF163@ajf.me>
Message-ID: <alpine.DEB.2.11.1409142119140.4267@whisky.home.derickrethans.nl>
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>
 <807E0A88-3643-4EE0-B96E-B779903CF163@ajf.me>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-201380720-1410726149=:4267"
Subject: Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
From: derick@php.net (Derick Rethans)

--8323329-201380720-1410726149=:4267
Content-Type: TEXT/PLAIN; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Sun, 14 Sep 2014, Andrea Faulds wrote:

>=20
> On 14 Sep 2014, at 13:17, Zeev Suraski <zeev@zend.com> wrote:
>=20
> > I honestly don't see why we can't be consistent for the simple=20
> > types, or at least strive to be as consistent as possible as opposed=20
> > to introducing a complete parallel universe for userland functions,=20
> > that's inconsistent with the entirety of the rest of PHP.  We don't=20
> > have to be consistent with ALL internal functions, which obviously=20
> > have the option of doing custom checks and return failures not only=20
> > if you fail to, say, pass on a string - but also if that string is=20
> > not of a special format.  But then, you have the option of doing=20
> > that also in userland functions using custom code. The question is=20
> > not the customized cases - it's the standard behavioral cases -=20
> > comparing zpp rules for scalars and the newly-introduced rules for=20
> > userland scalars.
>=20
> OK, we could go for exactly what zpp does already. However, then we=20
> don=E2=80=99t have a compromise. We are siding with what you want, but mo=
st=20
> userland developers would prefer a strict system. While this would=20
> please you and perhaps some other folk on internals, and sure, it=E2=80=
=99d be=20
> consistent, it would not be popular with the wider PHP community.=20
> Similarly, we could go for a fully strict approach, which might please=20
> some userland developers, but wouldn=E2=80=99t please you.
>=20
> I don=E2=80=99t want to go down this route. I=E2=80=99d prefer we comprom=
ise and keep=20
> PHP=E2=80=99s weakly-typed nature (an int can be accepted as a float or a=
=20
> string), but make it stricter (no data loss), thus arriving at a=20
> middle way.

But this "compromise" introduces yet another set of casting rules. And=20
that is why will advocate and vote against this.

We can either have casting where:

=09function bar(int $foo) { }
=09bar("42");

Means the same as:

=09function bar($foo) { }
=09bar((int) "42");

Or we can have it as a strict cast, or we can have it like it currently=20
(ie, not at all). I can live with those three options, but not an=20
option where casting/checking does something different again.

cheers,
Derick
--8323329-201380720-1410726149=:4267--