Trying to think what real world example may look like. With exceptions:
try {
$i = lossless_int($sth);
} catch (SomeException $e) {
// error out / provide default / custom error handling
}
If we use FALSE:
$i = lossless_int($sth);
If ($i===false) {
// error out / provide default / custom error handling
}
At first glance they look mostly equivalent, but it really depends on the
use case people will use it for. For instance, if you use it for input
validation for several input fields, the try/catch approach allows you to
put several conversions in one block, whereas the false approach doesn't,
and requires separate checks for every input field. There's still the
question on whether or not the exception would provide enough context for a
meaningful error message or not.
I think a key missing piece in the RFC is an explanation for the assertion
that the current type conversion system "[] makes it difficult to write
robust applications which handle user data.", and more importantly, how
these new functions will fix it. It focuses on how what these functions
would behave, but not so much about how real world usage of these functions
would behave.
My assumption is that with handling user input being the main goal, in case
of failed conversion the likely handling would be erroring out in case of
'garbage' input, as it's impossible to safely determine what were the remote
user's intentions (if we were to 'guess' what he meant with some default,
I'd argue that the current conversion rules are as good a guess as any). If
that's the case, wouldn't it make more sense to change the semantics of this
new family of functions from functions that do the conversion, to ones that
just check whether it can be done?
Something like:
If (!int_convertible($sth)) { // open to new ideas about the name :)
// error out
}
$i = (int) $sth;
Or even safe_to_conver($sth, 'int')) (i.e. one function that can handle all
types)?
Zeev
> -----Original Message-----
> From: Dmitry Stogov [mailto:dmi...@zend.com]
> Sent: Wednesday, October 22, 2014 1:28 PM
> To: Bob Weinand
> Cc: Andrea Faulds; PHP Internals
> Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions
>
> "null" or "false" return value would make these functions not really
> useful,
> because they won't guarantee to return desired type.
>
> printf("%d\n", to_int("abcd")); // will print 0
>
> The only reliable option to support wrong input is exceptions.
> On the other hand, exceptions maybe difficult to use or inefficient.
> We may avoid exceptions throwing, if provide a default value:
>
> function to_int(mixed $a , int $default_value = null): int; function
> to_double(mixed $a , double $default_value = null): double; function
> to_string(mixed $a, string $default-value = null): string;
>
> Thanks. Dmitry.
>
> On Wed, Oct 22, 2014 at 12:37 PM, Bob Weinand <bobw...@hotmail.com>
> wrote:
>
> > I know we have that already discussed a lot now, but I’d like to
> > expose my points on the return value here:
> >
> > I imagine code like (supposing that we ever will have scalar typehints):
> >
> > function acceptsInt (int $i = null) {
> > if ($i === null) {
> > $i = 2 /* default value */;
> > }
> > /* do something with $i */
> > }
> >
> > When we return false:
> > acceptInt(($tmp = to_int($_GET["userinput"])) === false ? null :
> > $tmp);
> >
> > When we throw an exception:
> > try {
> > acceptInt(to_int($_GET["userinput"]));
> > } catch (CastingException $e) {
> > acceptInt(null);
> > }
> >
> > When we just return null:
> > acceptInt(to_int($_GET["userinput"]));
> >
> > Also, when we want to pass a default value defined outside of the
> > function, it’s a lot easier now with the coalesce operator:
> > acceptInt(to_int($_GET["userinput“]) ?? 2 /* default value */);
> >
> >
> > Also, independently of possible scalar typehints:
> >
> > Generally exceptions are also a bad idea as the casts probably will be
> > used on external input and exceptions are **not** a way to handle
> > malformed user input. Really not.
> > Furthermore, false is a bad idea in the same sense (if we get scalar
> > type hints once), because people then might just catch the
> > EngineException…
> >
> > Also, null means "no value"; that’s exactly what we need. If the
> > to_{type}() functions cannot return a meaningful value, just return
> > "no value", that means null. And not false, which is a real value.
> >
> > That’s why I strongly feel that null is the only true thing to return
> > here.
> >
> > Thanks,
> > Bob
> >
> > > Am 21.10.2014 um 00:57 schrieb Andrea Faulds <a...@ajf.me>:
> > >
> > > Good evening,
> > >
> > > I am presenting a new RFC to add a set of three functions to do
> > validated casts for scalar types:
> > >
> > > https://wiki.php.net/rfc/safe_cast
> > >
> > > Please read it.
> > >
> > > Thanks!
> > > --
> > > Andrea Faulds
> > > http://ajf.me/
> >
> > --
> > 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
