So, what exactly changes here if we have a second parameter or just return null
by default?
It doesn’t make any difference, it’s just another way to write it:
to_int($a, $default)
or
to_int($a) ?? $default
Also, if you want exceptions, you always can wrap a userland function around it
— but I’d rather not wrap an userland function around something throwing an
exception… inefficient and weird.
Thanks,
Bob
> Am 22.10.2014 um 12:27 schrieb Dmitry Stogov <dmi...@zend.com>:
>
> "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
