Hi, 2015-10-29 17:43 GMT-03:00 Stanislav Malyshev <smalys...@gmail.com>: > Hi! > >> Well yes, but the interface description currently says that it'll return >> a value of some unspecified type. That's what omitting the return type >> declaration does. > > No, it doesn't do that. It doesn't do anything - it just provides no > information. If you rely on it to return something, then the interface > should be modified accordingly, or the documentation should be. >
If you're implementing an interface from some external package, you certainly won't have any interest to "modify the interface accordingly". And by "providing no information" you leave interpretations open to both: - "this method may return null" - "this method may return bool, array, int, string, Foo, Bar\Baz, null or anything else" Knowing how humans work, you don't really expect that every person will inspect each implementation they're using to see if it honors the interface's intentions. >> I don't think extension can be harmless. People will unintentionally >> rely on such added behaviour unless you force them not to. While it's > > If people rely on behavior that is not defined as part of interface, > they are using interface wrong. void would not help them there - just > saying "void" does not prevent anybody from still violating the rules > and trying to use the return value. > >> not ideal, programmers do not look up the documentation and carefully >> read it every time they use a function. They will make mistakes. > > Surely they will. But adding void does not help avoiding them - if they > won't look up the functions they are calling, they wouldn't know it is > "void" and thus would feel free to use its return value. "void" or "null" as return type would give a 100% guarantee that every possible implementation of a given interface won't return any random value. Then it would make no difference if the returned value is being used or not, as it would always be null. So, it obviously solves the problem presented. There's not much to dismiss here. > -- > Stas Malyshev > smalys...@gmail.com > PS: It is curious that, originally, this RFC was proposed without considering the good impact it could have on interfaces... so I wonder what were the motivations behind it in the past :D Marcio. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
