Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75447
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_D89F75DC-578B-4A02-AFB1-8603EA5808F9"; protocol="application/pgp-signature"; micalg=pgp-sha512
In-Reply-To: <16D48604-0C0A-4613-91A4-21392E3A2636@ajf.me>
Date: Mon, 14 Jul 2014 17:12:18 +0400
Cc: PHP internals <internals@lists.php.net>
Message-ID: <DAE582FE-DABD-42DD-A0C3-ACB5C1BEA6AD@gmail.com>
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <16D48604-0C0A-4613-91A4-21392E3A2636@ajf.me>
To: Andrea Faulds <ajf@ajf.me>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: indeyets@gmail.com (Alexey Zakhlestin)

--Apple-Mail=_D89F75DC-578B-4A02-AFB1-8603EA5808F9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On 14 Jul 2014, at 16:58, Andrea Faulds <ajf@ajf.me> wrote:

> One of the issues with the RFC as it stands is how to handle bool =
casting. While int, float and string only allow lossless casting (with =
the exception of objects, but we can=92t really do anything about that), =
bool=92s behaviour at the moment is quite different. I don=92t think it =
makes sense so I won=92t discuss the current behaviour, only possible =
new ones.
>=20
> One option is simply to forget about being lossless and make the bool =
type hint accept any value, meaning any truthy value or any falsey value =
would yield what is expected without error. This would ensure that if =
some stupid programmer (like myself ;) has passed in a non-boolean =
truthy/falsey value to your function, it=92ll be handled correctly. It =
would mean all your bit hacks ($foo & FLAG etc.) would work, anything =
you got from $_GET (e.g. ?foobar=3D1). However, this is unlikely to =
catch bugs in code, because literally any PHP value would work. For that =
reason, I=92m not sure this is the way forward.

I don=92t think that "scalar casts=94 should do any additional =
error-catching. they target a very different usecase.
It shouldn=92t guarantee correctness of the whole program. It should =
guarantee that variable types are fixed inside of function.

In my opinion, this patch should act 100% similar to zpp.
And if, at some later point zpp-behaviour changes similar change should =
happen to userland "scalar casts"

Some people talk about inconsistency, which is introduced by reusing =
same syntax for "strict parameter types" and "scalar parameter casts=94. =
There=92s some truth there.
Let=92s use different syntax.

This might work:

    function foo((int) $a)
    {
        var_dump($a);
    }

I would read it as declaration-level casting

--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc




--Apple-Mail=_D89F75DC-578B-4A02-AFB1-8603EA5808F9
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJTw9dFAAoJEMkJcRxZdR27POsH/2LtsXn9Bk8oiIa3MtePPJV9
9LjK4SzrGpaDKf7U8sAtFh/DVzKhONDbFSu3nznQhkKLox+b1oZGm+hgoDU0poGb
40jJV1yAr/96lU9kNlN9hbWJe5RsBN7I3qh2ghUNCslC6ota1lGpWD/r4qP6E26o
THid//7KLUXTZ8JQk1BNhNtWxGLZaumTB9IkqaJPch7PqLklxSAT0aGgF+gN9rvt
jq7YxBzAqyK5UyEZStPUJoqz4qJgZw4y9oHf6nHtLEyh7HtSHYInN9ltIFxy416X
BsIY/oq6B2MXYnrybZN9td+PQmBkZgKjpDqp4J+l1rfxvvcEaPktAh5dsSETfuw=
=xnUa
-----END PGP SIGNATURE-----

--Apple-Mail=_D89F75DC-578B-4A02-AFB1-8603EA5808F9--