RE: [PHP-DEV] Scalar Type Hinting

From: Date: Thu, 08 Mar 2012 09:39:47 +0000
Subject: RE: [PHP-DEV] Scalar Type Hinting
References: 1 2 3 4 5 6 7 8 9 10 11 12  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
From: Arvids Godjuks [mailto:[email protected]] 

> > I like that. What should we do if this appears? As it's now - just 
> > throw an "Catchable fatal error" and let the script blow-up? I would 
> > go this far.
>
> I think "Catchable fatal error should" be fine and users are familiar with such
> mechanic because it already exists. Consistency, man, consistency :)

Yeah, I was a huge advocate of this too until recently. I've changed my mind though, ironically
enough to ensure better consistency.

PHP since 5.3 gives an E_WARNING if you pass poorly-converting scalar data to an internal function
(For example, substr('foo', 'bar');) This changed my mind about the level of
error to raise here. I think there's still a good argument for E_CATCHABLE_FATAL if you pass
something retarded (like a resource, or possibly even an array), but I think we should strive as far
as possible to be consistent with the behavior of scalars passed to internal functions. This would
allow us to repaint the entire proposal as bringing to the language level the same level of scalar
typing available internally, using the same syntax as the docs (which sounds much more reasonable
and less politically charged than "Please add scalar typing...again".)

See Ferenc's reply about 30 seconds ago for more details on this...

> > Type hints are meant to
> > filter input from external sources
>
> Correction, it should read like this:
> Type hints are _not_ meant to filter input from external sources

That's not really the point though. The issues with external sources providing strings comes
into play regardless of whether people validated their inputs. For example, if
(is_numeric($priority) && $priority >= 0 && $priority <= 3) will pass and
still leaves you with a string, and that string currently works just fine everywhere as if it were
an integer. What's more, the folks that will be voting on this have made it clear in the past
that failure to account for type juggling in any such proposal is a deal breaker. For many users
these inputs can and will trickle down through the code and eventually cause frustrating failures if
not handled intelligently. You don't have to love it, but basically if you want a typing
proposal to have any chance I think you'll have to support it.

John Crenshaw
Priacta, Inc.


Thread (43 messages)

« previous php.internals (#58771) next »