On 12/05/2016 14:46, Lester Caine wrote:
The key element *I* of cause am miss reading is the (Bar ...) which is a
type hint. That will not exist in any of the code prior to ? and that is
the key to what is being discussed. No type hint ... no change?
If someone 'improves' a third party library by adding type hints then
this is were the using code needs to be checked?
Correct. It should be no different from what can be done with existing
type hints - if I change a library you were using from "function
foo($bar)" to "function foo(Bar $bar)", it's possible you were passing a
different object in and will now get an error.
If my library was always expecting Bar objects anyway, I'm arguably
doing you a favour by forcing you to fix a long-standing bug where you
passed the wrong thing.
The way I like to think about type hints in PHP is sugar for assertions
at the top of the function:
function foo(Bar $bar) {
#...
}
is roughly equivalent to:
funtion foo($bar) {
assert($bar instanceOf Bar);
#...
}
The new syntax is just a different sugar, so that:
function foo(?Bar $bar) {
#...
}
is roughly equivalent to:
funtion foo($bar) {
assert(is_null($bar) || $bar instanceOf Bar);
#...
}
If the language didn't support typehints at all, I could add assertions
like that in my library, and cause basically the same behaviour if you
call my functions the wrong way.
[Strictly, in PHP 7, it's more like "if ( ! CHECK ) { throw new
TypeError; }" rather than assert(), but the default result is the same.]
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
