[RFC] Return type-hint

Hey All,
I'm really interested on this topic.

What would be the result of this?

function Foo foo($something) {
if ( $something ) {
return new Foo;
}
// no return implies return null
}

How do you force to return a Type with null allowed?

That is why I suggested, in addition to the above, a syntax like:

function (Foo | NULL) foo($something) {

to be able to specify where a function can return more than one type.
The 'extra' types/values are nearly always either NULL or FALSE.

Regards

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h

Here's my issue:

We're borrowing a feature from strongly typed languages and forcing it on a loosely typed language. I'm fine with this, if we're true to the concept.

In a regular language, if you type something to return an object of type Foo, you might still get back null, and appropriately need to check for this. NULL is a perfectly valid state for an object.

The objection I'm hearing to this is that because in PHP, null is a value and not a state, and since variables don't have types (values do), null should be an explicitly specified hint.

To me, this is a nuclear bomb waiting to go off. If we allow the syntax described earlier (Foo | Bar | Null) we're violating the concept entirely, and there's no point in even having the feature. If a developer can type hint a function in such a way that you don't actually know what you're getting besides a subset of types, this has the exact opposite effect that return hinting is supposed to have. Now, I have to check for what type the value returned is, on top of null. Why even use return hinting?

The other suggestion I've heard is to only allow for Object || Null, but this too seems ridiculous. The idea would be that if you're in a situation where you can't feasibly return the specified object, you should throw an exception. So now your code is going to be riddled with things like ObjectIsNullException, or generic handlers that don't know what to do besides go "OOPS!" when this happens. OR, you force default values down your object's throats. This is bad when the object you're using is volatile, and writes to a database or something.

The complain is that implicitly allowing null returns means you have to check for null even if you're expecting an object. But you have to do this anyway if you're not hinting.

+1 for return type hinting
-1 for explicitly specifying null
-100000000 for specifying multiple return types

Hi!

There will also be advantages for HipHop which can afford to spend the time to
do static analysis of code -- I know that HipHop is not your baby
but you now need to recognise that there is more than one PHP implementation
and features that may not had much advantage with Zend may be useful elsewhere.

If you want a statically typed language, there are tons of these on the market. However, unless you change PHP into another - statically typed - language, I do not see how it really helps.
What you talking about here is creating a dialect of PHP targeted for statically-compiled environment. I personally see it a bit pointless, since there are already many perfectly good static languages on the market, with excellent compilers and environments - so why not use any of these? But that shouldn't deter you - my personal opinion is just that, if you want to create your own static PHP, go ahead. But I do not believe doing it in little tweaks would work - if you want reliable typing, you need it everywhere.

However, I seriously doubt PHP as a whole would benefit from it. Most uses of PHP are very dynamic and would not yield serious benefits from introducing static typing constructs beyond very specific cases in very specific environments. Changing the whole language to benefit these narrow scenarios does not seem beneficial to me.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

On Fri, Apr 29, 2011 at 7:04 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:

Hi!

yeah, but usually you return null/false in case of error when you write

procedural code.

Nope. I use it all the time when writing OO code and when "nothing" or "no
object" or "can't do this" is a valid answer for a function to return.

but since we wouldn't support the return typehint for scalars, maybe we

could assume that the only sane people who would use this feature would
also do the error handling will through Exceptions (@throws :P).

Exceptions are for exceptional situations. If you query a DB for an
object and there's no object like this, you don't want an exception if this
situation is normal and handled in your code - you want a null or false or
something like that. Exception is for situations that you code can not
foresee or handle, they are not for regular data flow control.

some agree, some disagree with that.
http://barelyenough.org/blog/2007/11/when-to-use-exceptions/

Tyrael

Martin Scotta

2011/4/28 Martin Scotta martinscotta@gmail.com:

• snip *

IMHO I would not trust on any return value, as PHP did not ensure
anything
about them.
Even more, I do not write code that depend on return values, I prefer to
use input/output parameters,

I cannot help but wonder why PHP is your language of choice. I mean no
disrespect, but PHP does not have strict typing (for a reason) and
forcing it upon PHP seems strange to me. Seeing as a) you'll either
have to implement the return type hinting yourself in which case you'd
know anyway what the return value is or b) you'd have to have others
implement it in their libraries in which case you'd have to wait years
for any noticeable effect, the feature seems useful only in edge cases
(such as Hiphop, which I think one can question the mainstream
usefulness of, currently).

I understand why PHP does not have strict typing as much as I understand why
PHP do not have good-qualities third-party libraries.
I'm not saying that there aren't good libraries, but the language has many
holes that makes almost impossible to build solid library (ie: include)

All the strictness of ppp, typehint and the like are not restrict things,
they are meant as boundaries for client code, to ensure the correct and well
defined behavior.

It's ok if you write all you code as procedural, or you don't like to write
classes, but IMHO the language should provide a solid foundation for them,
this way you can rely on libraries for common task and make your procedural
code even simpler, shorter and safer.

I'm not sure if return typehint will be a good idea, but I'm not against it.
I believe the language has to deal with other "pending" stuff prior to this.
PHP has many blind areas, whenever you call something, you don't know if you
will return or it will just die in a non-sense Fatal error.

Personally, I read code if I'm not sure what a given function/method
will return - or just test. I actually thought unit tests took care of
issues like this. I don't think having a list of possible return
values would make things simpler than the good old "try it and see" -
which is one of the greatest assets of PHP.

This is the safer way I've found to achieve the same behavior

function no_return(ReturnStatus $returnStatus) {
doSomething();

if ( itWasOk() )
{
$returnStatus->setReturnValue( new Foo ); // return type hint
$returnStatus->success(); // return status
}
elseif ( isWasCritical() )
{
$returnStatus->setException( new RuntimeException );
$returnStatus->exception(); // return status
}
else
{
$returnStatus->fail(); // return status
}
}

Of course I don't write all functions like this.
This is pattern I use when I need to ensure that the type returned is
valid.

I just return what I need to from the function/method or throw an
exception. Indicating that you want to throw an exception instead of
actually throwing one seems ... overly polite, at best. As far as I
can tell, you'd have to check the ReturnStatus object anyway, so I
don't see how you're any safer (PHP has functions for checking null
values, false values, try/catch blocks and other things too). But
maybe we're dealing with very different development environments and I
just cannot see the usefulness of the suggested as it wouldn't make a
positive difference in mine.

Just a perspective from a typical webdev.
Regards
Peter

--
<hype>
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
</hype