Lester Caine wrote (on 14/07/2014):
On 14/07/14 16:41, Andrea Faulds wrote:
The irritating thing here is HAVING to add the error_handler which may
well have been installed already for other reasons ... possibly in some
third party library to compensate for other changes?
The intention is obviously that you wouldn’t skip the E_RECOVERABLE_ERROR, but
my point was that if you really wanted to, you could. The other type hints are
strict, hence this one is too, it’s just tolerant of equivalent values that can
be losslessly converted.
If you want to pass user data safely to such a function, (int) or (float) first
is probably a good idea.
Personally I like to handle the miss matched data and give the user a
sensible response for each data item. This is only practical by
individually handling each passed item so I don't want some other
mechanism getting in the way of SIMPLY handling a data entry and it's
miss matches. Often text has been added in the wrong place, and one can
process that with a sensible response, something that creating a global
warning/error does not allow. If I check for 'int' and it fails, then
there may be something else entered that needs to be handled next rather
than breaking out of a normal program flow by trapping the 'mistake'.
Much of the error handling added these days breaks a logical program
flow ...
That sounds like a job for a full-feature input validation routine, not
a language construct. A type-hint of DateTimeInterface does not imply a
pluggable error-handling mechanism for invalid date inputs, but nor does
it get in the way of you writing one. Rather, it's an assertion that
having run such a mechanism, you are only passing the successful values
in, not the error signals.
This is why I like the mixed-mode scalar hints: if you want to allow
'three' to be interpreted as int(3), you need custom code to do that,
and no type hint should do that for you. However, if you have user input
of '3', it's a useful base case to treat that as a valid input.
But maybe what I'm really after has nothing to do with type hints at
all, but an easy way to ask explicitly for a "strict cast": "is this
input an integer, or a string which *definitely* represents an integer?"
- either giving me an error (e.g. $foo = (strict int)$foo) or just
returning a boolean (i.e. a much more restrictive version of
is_numeric() or less over-engineered version of filter_var()).
For that matter, most of the suggestions in this thread could happily
exist outside of function signatures:
- lossy casts we already have, both explicitly and implicitly
- assert(is_int($foo)) is basically the same as a strict type hint
- a new type of cast that emits a notice would be as easy to add as a
new type that emits an error - the main stumbling block is inventing
some syntax for them
- making implicit casts emit a notice on lossiness would be possible,
though potentially disruptive to existing code
The debate in this thread basically comes down to us each wanting our
favourite from that list of features to have the privilege of dedicated
syntax in function signatures.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
