> -----Original Message-----
> From: Anthony Ferrara [mailto:[email protected]]
> Sent: Monday, July 14, 2014 7:25 PM
> To: Zeev Suraski
> Cc: Rowan Collins; [email protected]
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
>
> Zeev,
>
> > Actually there's a pretty simple way that's not strict type hints:
> >
> > 5) Add type hints using existing syntax, which are casts; Change
> > casts (both existing and these new ones) to emit a new E_CAST in case
> > of data loss or 'bogus' conversions.
>
> The issue with this, is that it changes how your calling code will behave
> based
> on global configuration. Not an issue for the application developer (since
> they
> can control the global config), but for a library developer who makes
> reusable
> code, this is going to become a nightmare to deal with.
>
> Example:
>
> function foo(int $bar) {}
> foo("12abc"); // May silently succeed. May raise E_CAST error. May
> throw
> exception. Who knows!
That's true for E_RECOVERABLE_ERROR in the exact same way. We're only
arguing the 'default', in both cases the actual behavior will be affected by
global error handlers if they exist.
> That sounds like it's not a big deal, but it will result in calling code
> needing to
> get extra defensive to be robust:
>
> try {
> foo($something);
> } catch (\Exception) {
> // I have no idea what exception may have been thrown here
> }
>
> Or ignoring the error entirely by "forcing" the unknown value to an
> integer:
>
> foo((int) $something);
>
> Which is exactly what this RFC was designed to avoid.
I fail to see how it avoids it... An app developer using an API that
expects an int, and that has an integer-looking-string coming from the end
user or a file, will simply stick an (int) there to avoid the API from
complaining about extra spaces or even superfluous characters.
> And that also hints towards a benefit of adding a numeric hint as well
> (which
> will accept (and cast to) either an int or a float, exactly how
> is_numeric_string() does internally)... Which is something that may want
> to be
> considered for this RFC.
I definitely agree with this one (it's in
https://wiki.php.net/rfc/typecheckingstrictandweak )
> That would again result in (int) casts being used, which would then hide
> the
> *real* error cases, such as passing "apple" to a function expecting an
> integer...
If you care about it - you can easily spot it by paying attention to
E_CASTs. We're talking about runtime errors either way, if there was a way
to do 'compile time' error checking I'd see the point in going for errors,
but there isn't. And as a special bonus, if we change the casting code to
also emit E_CAST - then we don't just push people to find "apple" -> int
issues in that specific situation, but everywhere where there's a cast.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
