Thomas Bley wrote:
> Yes, we currently have negative values for invoices and positive for vouchers
> ...
>
>
> Christoph Becker wrote on 02.02.2015 22:17:
>
>> Thomas Bley wrote:
>>
>>> Here is a typical billing example which uses exceptions:
>>>
>>> <?php
>>> ini_set('error_reporting', E_ALL);
>>> ini_set('display_errors', 1);
>>>
>>> addVat('apples');
>>>
>>> function addVat($amount) {
>>> if (!is_int($amount) && !is_float($amount)) {
>>> throw new InvalidArgumentException('Argument 1 passed to
>>> '.__FUNCTION__.'
>>> must be of the type int|float, '.gettype($amount).' given');
>>> }
>>> return round($amount*1.19, 2);
>>> }
>>>
>>> Instead of multiple strict scalar hints (e.g. function addVat(int|float
>>> $amount){...}), I would prefer to have "numeric" as strict type:
>>> function addVat(numeric $amount){...}
>>
>> Have you considered
>>
>> addVat(-1);
Well, my point was that even a strict type system doesn't necessarilly
catch all erroneous/undesired arguments. Even if addVat() properly
handles negative numbers, and maybe even zeroes, there are functions
that can't.
IMHO strict typing in a dynamic language is overvalued. While it
certainly helps to catch some errors, it doesn't do so during compile
time, at least not for all cases (consider call_user_func() etc.)[1]
And frankly, I don't see what's wrong with a weak type hint in this case:
function addVat(float $amount) {...}
You're returning a float, anyway.
[1] There may be other benefits of having strict type hints. One of
these would be potential optimizations, but I have some doubts whether
this is feasible with optional weak/strict type hinting on the *call* side.
OTOH, strict type hints would require a lot of manual conversions.
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
