Hi! > There is a quite important use-case I've been informed of (alas I cannot > recall who by), and it was one of the things that motivated me to revive > the RFC. For interfaces, it's important to be strict in your > definitions, so you don't end up with implementation-defined behaviour > that people accidentally rely on. One of the problems that crops up is > that you can't currently specify that an interface method doesn't return > anything. This means that implementations sometimes add return values, > and functions get written that rely, unintentionally, on objects with > that interface having that behavioury. With the `void` type,
This is not the use case for void. This is just wrong usage of interfaces - if you code against interface, you can not rely on anything that is not defined in the interface description. I.e., if you are using the return value of the object declared as instance of the interface, then all implementation of the interface should return the value, and of the same kind at that. On the other hand, if the interface description does not contain any knowledge about return value of the function being useful, then you can not use it. And if you aren't using it, what would be the problem if the return value would be anything at all? I see it as fixing the problem on the wrong end - instead of fixing the code that uses interfaces wrong, you try to fix the implementations that do harmless extension of the interface, because of the fear that somebody could use the interface wrong. > implementations of an interface are forbidden from returning a return > value, so this issue goes away. The issue does not go away - if some code uses the return value, you still have to fix it. And after *that* code is fixed, there's no reason to limit the return value of the functions, since nobody is actually caring anymore about it. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
