Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44677
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.206 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type
         :content-transfer-encoding;
        b=XgJH+GDmYK/aztx9Cexty/KZuGu+SQ0fdP4uOk7anfXk+LefWTWdlHoSXY8ByJ12WQ
         MMWPY7LiC1gy2mLPTgrFm7e4AsusJZiwFQz9Y6EX6e8sVA/orOHGNnSjRbZCElJ+IgGz
         sfuUL0XeOB3bipZ7GjMPlgvALXFFGMnElDtQg=
MIME-Version: 1.0
Sender: david.coallier@gmail.com
In-Reply-To: <FC14FAFE-6785-4067-9B49-9FC14F159C52@prohost.org>
References: <FC14FAFE-6785-4067-9B49-9FC14F159C52@prohost.org>
Date: Fri, 3 Jul 2009 11:31:05 +0100
Message-ID: <b5f7bf6c0907030331r31ecc823t1d5df0a007491dbb@mail.gmail.com>
To: Ilia Alshanetsky <ilia@prohost.org>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
From: davidc@php.net (David Coallier)

2009/7/1 Ilia Alshanetsky <ilia@prohost.org>:
> There has been quite a bit of discussion on this list, IRC, developer
> meetings, etc... about introduction of type hinting to PHP. Most people
> appear to think that this would be a good idea, but there is a reason why=
 it
> is not in PHP already. The main source of conflict appears to be that in
> some cases typical type hinting is just too strict for PHP's typeless nat=
ure
> (most people expect that "1" =3D=3D 1, while int type hint would definite=
ly
> reject string "1"). =C2=A0Personally, I disagree with that opinion, but I=
 can
> understand people who raise that issue. At work we've been using PHP 5.2
> with type hinting for nearly 2 years now with great success, it makes cod=
e
> much easier to read and understand and the security benefit of type hinti=
ng
> is not to be under valued. In many cases type hinting can present a last
> line of defense against unexpected input for numeric fields, which are
> typically abused to do SQL injection.
>
> I've taken a few hours this morning to port my 5.2 type hinting patch to
> 5.3. In recognition of a need for a more 'flexible' numeric type I've
> introduced (numeric) type hint that would allow bool/int/float data types=
 as
> well as a string containing a numeric entity as identified by
> is_numeric_string(). For completion i've also added (scalar) data type th=
at
> will allow any scalar data element.
>
> The patch is available here: http://ia.gd/patch/type_hint_53.txt
>
> It should be noted that this patch is fully compatible with opcode caches
> and and requires no changes on the part of an opcode cache such as APC to
> work.
>
> My hope is that the latest changes will allow this to become a standard p=
art
> of PHP.


Brilliant stuff Ilia!

One thing I noticed in the patch is:

"+<ST_IN_SCRIPTING>("string"|"binary"|"unicode") {
+	return T_STRING_HINT;
+}
"

which makes sense if we keep for PHP6 but doesn't for 5_3 which afaik
doesn't have (unicode) casting yet :) I think that's nitpicking I
agree and I just want to make sure that this doesn't become a
documentation issue for people who'd think you can hint using unicode
or even see article saying you can hint with unicode.

Makes sense for PHP6 though but since you merged your patch from 5.2 I
figured I could ask :)

Apart from that this is awesome and am I glad that we are not trying
to cast automatically!

+1

--=20
Slan,
David