Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44712
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.185 as permitted sender)
Message-ID: <7.0.1.0.2.20090705112530.16320530@zend.com>
Date: Sun, 05 Jul 2009 11:30:28 +0300
To: Ilia Alshanetsky <ilia@prohost.org>
Cc: Tom Boutell <tom@punkave.com>,
 "internals@lists.php.net" <internals@lists.php.net>
In-Reply-To: <ADDA7BCF-9718-4FF0-A1DA-25AD7FE9BE0F@prohost.org>
References: <FC14FAFE-6785-4067-9B49-9FC14F159C52@prohost.org>
 <20090701171533.GI4355@mint.phcomp.co.uk>
 <e52c06b30907011022u29002986webfe5b8eb6aeb1a5@mail.gmail.com>
 <ADDA7BCF-9718-4FF0-A1DA-25AD7FE9BE0F@prohost.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
From: zeev@zend.com (Zeev Suraski)

I think there's a more fundamental flaw here than just pointing to 
'numeric' as an alternative.  The internal IS_* setting is 
meaningless for countless pieces of data floating around in PHP, 
arguably far more than the ones for which it truly represents the 
'semantic' type.  Continuing what Stas said, it's no coincidence our 
internal functions transparently translate arguments to the required 
types (except for the rare cases where it's not possible).

The other course of action is to change the implementation so that it 
behaves like the one for internal functions - with emphasis on 
conversion instead of validation of IS_*.  We can consider being more 
strict - and error-out on non-numeric strings instead of producing 
0;  If we were to start from scratch today, we'd probably do the same 
for internal functions.  Encouraging the equivalent of strict is_*() 
checks is very inconsistent with both our entire internal functions 
library, as well as the common behavior of PHP.  It doesn't come to 
say that it's not useful in some cases - but for these, using is_*() 
should be a suitable.

Zeev


At 20:40 01/07/2009, Ilia Alshanetsky wrote:
>Tom,
>
>Type hinting is optional you don't have to use it. However, the
>"numeric" type I've added specifically addresses that point.
>
>Ilia Alshanetsky
>CIO/CSO
>Centah Inc.
>
>On 2009-07-01, at 1:22 PM, Tom Boutell <tom@punkave.com> wrote:
>
>>I expect this would be a problem for folks who are relying on the fact
>>that they can parse configuration files and web inputs purely as
>>strings, yet numeric fields containing string representations of
>>numbers will actually behave as numbers if called upon to do so.
>>
>>Speaking of which, when I'm in a hurry and large numbers (or negative
>>numbers) are not dangerous in that particular context, I sometimes
>>validate a numeric field like this:
>>
>>$x = $_REQUEST['x'] + 0;
>>
>>And then assume $x will be a number - perhaps an obnoxious number,
>>maybe even a huge floating point number with an exponent, but a
>>number. Is there a flaw in that reasoning that I'm not aware of?
>>
>>On Wed, Jul 1, 2009 at 1:15 PM, Alain Williams<addw@phcomp.co.uk>
>>wrote:
>>>On Wed, Jul 01, 2009 at 12:59:59PM -0400, Ilia Alshanetsky wrote:
>>>>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
>>>>...
>>>
>>>Another desirable result of type hinting is that it would strengthen
>>>reflection ... one use of that would be automatic generation of
>>>WSDL files. This is something that I am currently struggling to do,
>>>not helped by the completely cr*p documentation of this - I am not
>>>talking about PHP documentation here by W3 & other places :-(
>>>
>>>+1 to type hinting.
>>>
>>>--
>>>Alain Williams
>>>Linux/GNU Consultant - Mail systems, Web sites, Networking,
>>>Programmer, IT Lecturer.
>>>+44 (0) 787 668 0256  http://www.phcomp.co.uk/
>>>Parliament Hill Computers Ltd. Registration Information: 
>>>http://www.phcomp.co.uk/contact.php
>>>Past chairman of UKUUG: http://www.ukuug.org/
>>>#include <std_disclaimer.h>
>>>
>>>--
>>>PHP Internals - PHP Runtime Development Mailing List
>>>To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>>
>>--
>>Tom Boutell
>>P'unk Avenue
>>215 755 1330
>>punkave.com
>>window.punkave.com
>>
>>--
>>PHP Internals - PHP Runtime Development Mailing List
>>To unsubscribe, visit: http://www.php.net/unsub.php
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php