On 28 May 2017 at 14:25, Rasmus Schultz <ras...@mindplay.dk> wrote:
>
> To me, that's a setback that leads to harder-to-debug errors, and increases
> learning-curve.
Everything is a trade-off. The type widening RFC makes it easier to
move to parameter types for existing libraries.
While I can see what you mean about how it could lead to more
accidental errors, for me at least, it would be actually quite hard to
not notice those errors in the code.
First, when people are programming against the interface rather than
the implementation, that type of mistake is much easier to spot.
function foo(Repository $repo) {
$repo->save(new stdClass());
// The above line is marked as an error in any decent IDE
// or code analysis tool.
}
Second, accidentally dropping the type from the parameter is also an
easy mistake to spot.
class UserRepository implements Repository {
public function save($item) {
// When inside this function the programmer has no idea
// what type item is. Any call to a method or property will
// be marked as a potential error either by an IDE, static
// analysis tool, or just the programmer realising
// "that parameter has no type".
}
}
So, to me (and possibly others who voted for the RFC) the ability to
add types to interfaces without breaking implementing library is a
good trade-off.
And yes, the type system in PHP could definitely be improved. Perhaps
you could propose an RFC? I suspect it might need to target PHP 8. I'm
personally hoping that some form of the union type RFC could return,
though possibly in a more general form.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
