Hi!
Well in summation I think this is something that should be implemented,
I don't see any arguments against implementing this atleast for arrays
and classes, like we already have for function parameters.
I think we had plenty of arguments against it last time it was
discussed. You could see it here for example:
http://marc.info/?l=php-internals&m=118478789527042&w=2
But I can repeat.
Return types are useful in statically compiled languages, since they
enable static type control. Since PHP has no static type control, return
type is useless for the function client - the fact that function returns
type X itself can be found in the documentation (where it belongs) -
that includes PHPDoc for the smarter IDEs out there - but code-wise
there's no useful action I can take using this information that I can't
take using just what function actually returns and be safer.
Return type definition can prohibit function from returning different
types, however here we have two problems. First is that function
definition and code is usually written by the same person in the same
(very small) context, and this person has to be somewhat absent-minded
to forget what function returns from definition to return a dozen lines
below. Supporting such absent-mindedness with language constructs
doesn't appear appropriate. Second is that only action return type
definition could take in this case is break the application in runtime,
which would be of little help to our absent-minded function writer and
especially to its client.
But even worse, since on the client side you have no way to enforce this
restriction, you can't even rely on it in any context - what if the
absent-minded function writer forgot to put the type restriction? If the
type was important for you, you'd have to check it anyway, since you
have no way to enforce the restriction on the client side! Since your
enforcement on one side and your usage of the data is on the other, the
enforcement is unreliable and thus useless.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
