Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34505
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <477FC27A.2070309@lerdorf.com>
Date: Sat, 05 Jan 2008 09:46:34 -0800
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: internals Mailing List <internals@lists.php.net>
References: <477DB7BF.10201@chiaraquartet.net> <20080104105558.GC7861@mint.phcomp.co.uk> <477E5649.2080104@chiaraquartet.net> <477E619C.2050107@sektioneins.de> <FCE5B4DC-F9BC-4C84-BF27-9CD86B3FBE1D@prohost.org> <477E78D0.3050501@zend.com> <CF90BE82-99A0-4E64-AD60-189FE98FDC74@prohost.org> <698DE66518E7CA45812BD18E807866CE01103ED3@us-ex1.zend.net> <1199472536.15292.185.camel@sbarrow-desktop> <698DE66518E7CA45812BD18E807866CE01103EE2@us-ex1.zend.net> <477ED01F.3090300@dealnews.com>
In-Reply-To: <477ED01F.3090300@dealnews.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] type hinting
From: rasmus@lerdorf.com (Rasmus Lerdorf)

PHP is first and foremost a Web scripting language.  Everything we do 
and every decision is based on that.  For every feature the first 
question you need to ask yourselves is:

   Will this make it easier or harder for the average PHP user to
   build a web app?  And if it makes it harder, is the extra pain
   worth the benefit?

Given that HTTP is still the dominant web protocol and given that HTTP 
is not typed, we have to be very careful about introducing stronger 
typing into PHP, even if it is optional.  Passing $_REQUEST['age'] to a 
function isn't a use-case that can be easily dismissed as it was by 
someone earlier.  This is the primary use case.  PHP takes scalar user 
data which comes across HTTP untyped, does stuff to it, and sends 
something back.

The argument that adding a type hint will make documentation easier is a 
scary one for me.  If we go and promote the use of runtime type hinting 
in order for people to use auto-documentation tools, they are likely to 
sprinkle these type hints everywhere which has the nasty side effect of 
causing runtime warnings or errors when something returns 1 instead of 
"1" whereas before this happily worked and worked correctly.  And short 
of fuzzing all your code, you aren't going to catch this case during 
development.

The robustness principle holds true here:

   Be conservative in what you do; be liberal in what you accept from
   others.

This means that "1" and 1 should be able to travel freely within a PHP 
script without tripping anything up.  And it means there needs to be 
ways for the code to be conservative in what it does with this data. 
Today this generally means casting and context-specific filtering.

Robustness and code correctness play against each other to some extent. 
  If you wrote your code in such a way that a function should always be 
passed 1 and not "1" then it might be nice to know when this isn't the 
case, which is what type hinting is all about.  PHP has always leaned 
towards robustness, so having your code break in this case goes against 
the spirit of PHP.

There are ways today to write code that is very strict in what it 
accepts.  It is possible that we can make it a bit easier to write this 
style of code.  But we have to keep this basic principle of PHP in mind 
and also keep in mind that the type check is only a part (and usually 
the fastest part) of the conservative data handling strategy.  The 
context-specific filtering, like making sure -1 doesn't turn into 
2147483648 in some unsigned backend, still needs to happen with or 
without type hints.

-Rasmus