>> - on-numeric strings not accepted. Numeric strings with trailing
>> characters are accepted, but produce a notice.
>>
>> I would rather not allow fancy conversions here. Any trailing non
>> white spaces characters should not be allowed. I know it is not what
>> PHP does now in some cases but this is really a fuzzy area and never
>> really matched any actual needs or usages.
>
> Yeah, I don’t like this behaviour much. I want to avoid inconsistency with
> the behaviour of extension functions (i.e. zend_parse_parameters) where
> possible, though. Since this has come up so much, I should probably make an
> RFC to change this aspect of ZPP’s behaviour.
That RFC should probably be voted on before this RFC proceeds into voting.
After skimming through the RFC I'm unsure what the following code would produce:
function test(int $a, int $b) {}
test("10.4", 10.6);
If a warning/notice is raised, fine. If it will just result in $a ===
(int)10 && $b ===(int)10 :
I agree that consistency is a sound reason for this behavior. However
type annotations (or whatever they will be called) should not only
ensure that a parameter has a certain type but that no data was lost
during the conversion. It is reasonable (assuming the target type can
handle the value) and fine to convert an integer into a float, a
float/integer to a string or any string that would satisfy is_numeric
into a float (or if no data was lost an integer) and hide it from the
developer (after all, that is was php is about). If a conversion might
result in data or precision loss the developer should be notified with
a hard failure. (E_RECOV, E_WARNING, I can still chose to ignore them
using error handlers or error_reporting settings).
Allowing data (I would also consider (string)'12a' => int(12) data
loss) or precision loss while converting a typed parameter would
reduce the usability of the whole addition.
If I'm in a situation where data loss is acceptable I could just leave
the annotation away and cast as I would've always done or not cast and
trust on php to do whatever is required.
However caring about data loss in these specific occasions( including
the string -> int example above) would forbid me to use type
annotations. As I would have no way of knowing and bailing out if the
original value was altered before it was accessible by my code.
If type annotations wouldn't go beyond the safety that php currently
provides by converting in specific contexts and casting what is the
benefit in adding them?
However, while I see issues with the RFC (that might be related to a
misunderstanding on my side) I like the general direction.
>> I am also not a fan of errors, exception, at least for methods, make
>> much more sense. I know it is relatively easy to handle errors as
>> exception but still, let do it right now.
>
> That’s be inconsistent with our other type hints. To get this changed, I
> think we’ll just have to wait for Nikita’s Exceptions in the Engine for PHP 7
> RFC.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
