On Thu, Apr 28, 2011 at 7:45 PM, Stas Malyshev <smalys...@sugarcrm.com>wrote:
> Hi! > > > I see many advantages of the introduction of return type hinting. >> - you can guarantee that your methods returns only what is explicitly >> stated (or else it blows up, the same as for arguments) >> > > You can't, because function resolution happens in runtime, so the only > point you know what the function called "foo" returns is the moment where > you're already calling it, not a moment before. > > it's the same as for the current argument type hinting. you can access that information via Reflection http://hu2.php.net/manual/en/reflectionparameter.getclass.php > > - it can save you from having to define the return type in phpdoc, your >> code can define it's behavior >> > > Why I need being "saved" from documenting my code properly? Anyway, the > function code defines the behavior, declaration of return type just ensures > function would fail in runtime if your code tries to return unexpected data > - but how is it helpful? The client of this function doesn't even know that > before actually calling it! why did we added ppp if people can define in the documentation(or in the method name :/) that which method is public and which isn't > > > - I think maybe the language itself could use that information, for >> performance, etc. improvements (we know that the return value will be >> > > That would need static compile-time binding of functions, which implies > static binding of includes, etc. - basically, compiling PHP code as a whole > in one monolitic application. I see > > > created runtime, but we can throw it away if it doesn't match the return >> type or something), maybe we can use that information to throw errors on >> compile time if we find a non runtime decided return value which doesn't >> match with the return type. >> > > Sorry, what is "non runtime decided return value"? And how is "compile > time" different from "runtime" in your opinion - when exactly that "compile > time" happens? > > Just throwing ideas around. when we parse the php code to opcode, the interpreter could use the typehint information to catch trivial cases(eg. we cannot tell that return $foo is valid, but we can tell that return FALSE is not valid if the typehint doesn't specify that). I hope this clears that up. Tyrael
