2013/6/26 Maxwell <m...@maxvandervelde.com>:
> Sherif,
> I have to disagree with you on this in the same way that we have type hints
> for input variables on methods, this could also be useful.
> Consider an interface with a getter method defined. As it stands now in
> php, they're not entirely useful, since you can't define what type of
> object your expecting from the implementer. That greatly reduces the
> functionality of an interface and this proposal gives solution to that
> problem.
>
> Florin,
> I think the overall concept is good, I want to see something like this in
> the future, but I think this might be the wrong approach. I don't think we
> should be hinting primitives. if we're going to have a return type hint on
> a method, I would have it match the functionality of the input type hints
> for functions we already have, where you can hint at an instance of an
> object type, such as Iterator or StdClass, or an array, but not hint
> primitives such as int and string, like I currently see in the draft.
> Also, you should be aware that your proposed syntax for the return type (
> <type> ) is interfering with:
> https://wiki.php.net/rfc/protocol_type_hintingand seems unnecessary to
> me.
Thanks Maxwell, you summarized very well what I was thinking about it.
So +1 from me for the general feature at a first glance, but it should
then be very close to what is possible with input type hinting.
It makes it possible to write interfaces that acts like specifications
and to easier the writing of:
class Foo {
public function bar($input) {
$return = Baz::foo($input);
if (!$return instanceof ReturnType)
trigger_error("Cannot divide by zero", E_USER_ERROR); //
or throwing some RuntimeException
return $return;
}
}
to:
class Foo {
public function <ReturnType> bar($input) {
return Baz::foo($input);
}
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
