Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58302
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
Received-SPF: pass (google.com: domain of dmgx.michael@gmail.com designates 10.216.134.157 as permitted sender) client-ip=10.216.134.157;
MIME-Version: 1.0
In-Reply-To: <CAL0xaBEYm7s7Hw-Av1-kkc8iR7-o_4E1_Qy=PowBifW6+xzK-g@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>
	<CAL0xaBEYm7s7Hw-Av1-kkc8iR7-o_4E1_Qy=PowBifW6+xzK-g@mail.gmail.com>
Date: Tue, 28 Feb 2012 18:02:44 -0500
Message-ID: <CAGovj_PnZ3yHZPVP1ax361YyUE-XGj0nM0YG0w93m_sWmQnagw@mail.gmail.com>
To: Arvids Godjuks <arvids.godjuks@gmail.com>
Cc: Simon Schick <simonsimcity@googlemail.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: dmgx.michael@gmail.com (Michael Morris)

Much of what you put forward here is why I don't want there to be a
weak/strong divide.  We can do "weak".  Strong not so much.  Current
syntax allows

$a =3D (int) 3;
echo gettype($a); // integer

$a =3D 'Hello';
echo gettype($a); // string.

Under the new syntax this happens.

int $a =3D 3;
echo gettype($a); // integer

$a =3D 'Hello';
E_WARNING raised
echo gettype($a); // integer

In other words, once the variable's type is declared, it WILL NOT
CHANGE.  If one doesn't want that behavior, don't declare a type, and
things will work as they always have.

On Tue, Feb 28, 2012 at 5:56 PM, Arvids Godjuks
<arvids.godjuks@gmail.com> wrote:
> Hi, Simon.
>
> Actually I also advocated for notices/warnings on conversion with data lo=
ss.
> What just has to be done - the rule table when notices/warnings are throw=
n.
>
> 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)
> {
> =C2=A0 =C2=A0return $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 hin=
t 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>, =
internals@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