I can't think of any case where you'd want to error out when given
'100 ' if it would accept '100' quite happily.
I'd lean towards a single cast semantic for this, and remove that
strict checking flag from zend_parse_parameters(); lazy dynamic type
handling for primitive data types is one of the cornerstones of PHP
IMO.
--Wez.
On 11/15/05, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> Jani Taskinen wrote:
> > On Tue, 15 Nov 2005, Rasmus Lerdorf wrote:
> >
> >>
> >> Pierre wrote:
> >>> On Tue, 15 Nov 2005 18:59:32 +0200 (EET)
> >>> [EMAIL PROTECTED] (Jani Taskinen) wrote:
> >>>
> >>>> If you pass bad data to a function, it should not warn you?
> >>>> I'd rather have it as a FATAL error. :)
> >>>>
> >>>> Nothing to fix here, move along. (and fix your code..)
> >>>
> >>> PHP is losely typed, I see nothing wrong to pass an integer as string
> >>> there (for example, imagecreate("100", "100"); works).
> >>
> >> The question isn't what to do with "100","100" but what to do with
> >> "100abc","100abc". Should that still work? The old
> >> zend_get_parameters() following by a convert_to_long() says Yes. The
> >> newer zend_parse_parameters() says no.
> >
> > With new version it's possible to catch such typos, with old one they'd
> > just be silently ignored and perhaps could cause very hard to find
> > bugs in your code..
>
> I suppose, but I still find it weird that:
>
> date("h", (int)$foo);
>
> and
>
> date("h", $foo);
>
> will behave differently when $foo isn't a clean numeric string. And
> when we move 100% to zend_parse_parameters() in PHP 6 there will be many
> more functions changing their behaviour due to this.
>
> -Rasmus
>
> --
> 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
