Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58299
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
Received-SPF: pass (google.com: domain of arvids.godjuks@gmail.com designates 10.180.95.1 as permitted sender) client-ip=10.180.95.1;
MIME-Version: 1.0
In-Reply-To: <CAJWj5+G0wUgZxmZ3OZe7-PYbDoQ2DXXZmyNfcVCJm_54Mtf04Q@mail.gmail.com>
References: <CAG=uTXEfTBqX7n0_zfGjB_txQFKtZXF4MOo6RHHPSRPerGeKZA@mail.gmail.com>
 <CAKOpQSwP_VXazO1WgQgOWiKTmgiwzorg2=ii+Mdz58a=TKs6VA@mail.gmail.com>
 <CAGovj_O5UQx9aAaYg302i-kKp13CtBKNLmQ48OLHNvk61rM1sw@mail.gmail.com>
 <1330357150.2159.30.camel@guybrush> <CAGovj_MUt60EJfG8a7r-cqrC2PKsi8mqh6v_iyNoRDq8q-jh2Q@mail.gmail.com>
 <CAH-PCH6Bre5yzc6r3zxEj3=zZY0PHDOCVQ0s=f8JBDSPnK+5Fw@mail.gmail.com>
 <CAAyV7nFmfhb97CGAK1ZAkp9qb3oCPxbUDnS-Z-v3cP2APcYs=g@mail.gmail.com>
 <CAH-PCH5mYpAJAyMoyODDSwTvmgpf6ZN_dmC58v0b=K-s-mL0EA@mail.gmail.com>
 <CAAyV7nEpCWE2Gg5MCvfyhGGspgMGB+oYORKK=BKfm48sgXkROA@mail.gmail.com>
 <4F4C1324.2040905@gmail.com> <CAKOpQSzop8NuwnD1gPYmgzE2=E5_AHj_N+-ezTp4DFpHXktTqw@mail.gmail.com>
 <A633CF2D7C7BED41B41F1E64F25507B8069DC46C55@MAILR001.mail.lan>
 <CAKOpQSyptTG2=+QtxZoDAB9uh=T=Jgw0DzsAEpTSPv5fGLY7mw@mail.gmail.com>
 <CAL0xaBE9Gnw0teC_VBkGU9Z99g0yZKcu4gnVKqQk6FpfiKt0UQ@mail.gmail.com>
 <CAMyk_Abp7F+EgQe-0o4r79-6=QS_hpm54D4vDEgHzpJdWA9=1A@mail.gmail.com>
 <CAGovj_OudJnF5gRbZFUaffDnvn+1krsM1UDw7AN87sdXK3jVmQ@mail.gmail.com>
 <CAL0xaBFxVaQ8AbuuP6CuQOT3G1rYbOJtT4v7ZfWde5e9fEpF-w@mail.gmail.com> <CAJWj5+G0wUgZxmZ3OZe7-PYbDoQ2DXXZmyNfcVCJm_54Mtf04Q@mail.gmail.com>
Date: Wed, 29 Feb 2012 00:56:20 +0200
Message-ID: <CAL0xaBEYm7s7Hw-Av1-kkc8iR7-o_4E1_Qy=PowBifW6+xzK-g@mail.gmail.com>
To: Simon Schick <simonsimcity@googlemail.com>
Cc: Michael Morris <dmgx.michael@gmail.com>, internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Scalar type hinting
From: arvids.godjuks@gmail.com (Arvids Godjuks)

Hi, Simon.

Actually I also advocated for notices/warnings on conversion with data loss=
.
What just has to be done - the rule table when notices/warnings are thrown.

What I have in mind is no variable type hinting at all. What I want to
see is function/method type hinting.
And, because the zval actually has type in it, you actually already
weakly type hint the variable anyway:

$a =3D 1;
echo gettype($a); // integer

$a =3D (int)"1";
echo gettype($a); // integer

$a =3D (string)1;
echo gettype($a); // string

And so on. This part is in the language, just has different syntax.

So no-no-no from me on this:
int $a =3D 1;
int $a =3D "1";

It just duplicates the functionality. And I don't like the strict int
$a =3D 1; I have already explained why it's not a good idea from the
technical standpoint.

So what I want is this:

function int test(int $a, int $b)
{
    return $a * $b;
}
test(1, 2); // 2;
test("1", 2); // 2
test("1aaa", 2); // E_NOTICE or E_TYPE and result 2
test(array(2), 2); // E_RECOVERABLE_ERROR - just like with array type hint =
now.

It's really what the most people want. Simple, easy to pick up (object
and array already have this) and is just optional.

I purpose to deal with this and when it works and is released to the
wild then see if more strictness even is needed. I think this simple
weak type hinted functionality will suffice.

---------- Forwarded message ----------
From: Simon Schick <simonsimcity@googlemail.com>
Date: 2012/2/28
Subject: Re: [PHP-DEV] Scalar type hinting
To: Arvids Godjuks <arvids.godjuks@gmail.com>
=D0=9A=D0=BE=D0=BF=D0=B8=D1=8F: Michael Morris <dmgx.michael@gmail.com>, in=
ternals@lists.php.net


Hi, Arvids

I do understand your arguments ...

For me personally it's mostly to separate between string and numbers.
A string to number transformation is most-likely not without loosing
something ... This is most likely the reason why I want to have a
E_STRICT or E_NOTICE if something like that happens. Same appears to a
transformation of a number to Boolean.
I don't really care how variables are handled in the very inner part
of the php-core as long as it's effective ;)

As you're talking about serialization ... that's right ... If you're
serializing an array containing strict variables would require a
change.
Here you'll have a big downwards-compatibility-break ...

We can do this discussion endless ... but I think you got the point
why I want something like this.
Until now I trusted my IDE (PhpStorm) that's reading the PhpDoc of a
function and marking it as warning if I try to put in an integer
whereas the documentation says that this function expects a string (or
an error if it should be an object or array).

Bye
Simon