[PHP-INTERNALS] Type-hinted return values in PHP5?

Since there isn't any comments on this, should I have posted this
elsewhere? or is it just that no one is interested?

David Duong wrote:

It could be interesting to know, if the reason why this hasn't been
implemented already, is technical one, or a design decision?

Most likely no developer with enough knowledge had the
motivation/need/whatever to sit down and implement this. Don't forget
that most work on PHP is done on a voluntary basis so some features
which might look interesting for a few users might have lower priority
for developers.

To the original question: The patch might be applied to a 5.3 branch,
maybe. Not to 5.2 since it would break BC. A 5.3 branch is not yet
planned so there's no decision about what is being merged there from
head or not.

johannes

I think it's design one since nobody took care to design it :) I
personally don't see much need for it, since PHP is not a compiled
language, so there's little use for specific syntax of prescribing value
types. Since PHP has no concept of variable type, it's not clear what
return type hinting would give you that good documenting practices and a
decent IDE won't.

It would give you similar benefits to input type hinting, but instead of
"Functions are now able to force parameters to be objects...", it would
also read "Calling functions are now able to expect return types to be
objects...". If a function was defined to return object Z, but instead
returned false, then obviously there is something wrong and it could be
caught before calling code sees it expecting it to be something else.

This feature does not replace good documentation, good testing, or
provide any new functionality that could not be recreated by other
means. However, it provides a different and often better solution to
common problems. Many current PHP projects already have some sort of
"module" or "plugin" system how they make use of modules and return type
checking (if at all) vary wildly. With THRs future projects would be
able to make use of a slightly more advanced language with better
support for modular programming.

If I, or someone else decided to make a patch for this, and assuming it
worked exactly like I described, would it be accepted?

Stanislav Malyshev wrote:

Catching language-level error in application code is usually harder than
just handling it in user code. And if you are talking about distinction
between false/null and actual object, language level is the wrong level
to catch such things.
If you handle the error in runtime, you could have the check as well. If
you don't, the script breaks anyway, so it is not going to help you much.
Even more, the return value is the product of the module code, while
input values are product of the outside code. So when you say "I'm going
to process only type X, and I make a requirement for others to pass only
X to me", it makes for me more sense than saying "I'm going to return
only type X so I'm making restriction for myself to return only type X".
The latter is more like declaring variable types, which have its
functions in compiled languages but usually is not happening in dynamic
interpreted languages.
Also, since from the client side there's no way to check if the function
you are calling actually does have the return type restriction, it's
quite hard to program basing on that from the client side. So you
actually check it in one place (library) and use it in entirely
different place (client) which is usually bad idea since the client
becomes too reliant on internal details of the library.
I don't know... I personally don't see much use for it, but others may
disagree.

I think the only serious advantage I could see would be to allow
context-assistance IDEs more data, so they could provide method-completion.
As nice a feature as that would be, I don't think it's worth modifying the
language syntax for. I agree that in a loosely typed language that sort of
thing needs to be checked by the application code anyway.

And Zend Studio does this for you already, if you use comment your code
correctly. I really don't see a good use for this, either.

Jeremy

-----Original Message-----
From: Larry Garfield
Sent: Saturday, July 28, 2007 6:05 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Type-hinted return values in PHP5?
instead of
would
be
instead
be
else.
it
I think the only serious advantage I could see would be to allow
context-assistance IDEs more data, so they could provide
method-completion.
As nice a feature as that would be, I don't think it's worth modifying
the
language syntax for. I agree that in a loosely typed language that sort
of
thing needs to be checked by the application code anyway.

On one hand I agree, since PHP is so loosely typed. But it's hard to make
the argument that type-hinting return values is pointless, since PHP allows
(class) type-hinting with parameter values. I personally think type-hinting
is very nice, and not for the purposes of IDEs.

For example:


class Test {
function blah(mysqli $db) {

}
}

This validates at the language level the value passed is an instance of
mysqli. That is much more handy than doing this each time:

class Test {
function blah($db) {
if ($db instanceof mysqli)
.....
}
}

If one of the best selling points of PHP is its typeless environment, then
why make any of these available? It appears that we are moving more and
more towards what PHP was meant not to be. Of course, that is part of
evolution and adaptation; adapting to user demands.

I think it would personally be nice if type-hinting was available for
functions/methods and not variables (at this point).










-----Original Message-----
From: Jeremy Privett
Sent: Saturday, July 28, 2007 7:21 PM
To: Larry Garfield; internals@lists.php.net
Subject: RE: [PHP-DEV] Re: Type-hinted return values in PHP5?

And Zend Studio does this for you already, if you use comment your code
correctly. I really don't see a good use for this, either.

Jeremy

-----Original Message-----
From: Larry Garfield
Sent: Saturday, July 28, 2007 6:05 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Type-hinted return values in PHP5?
instead of
would
be
instead
be
else.
it
I think the only serious advantage I could see would be to allow
context-assistance IDEs more data, so they could provide
method-completion.
As nice a feature as that would be, I don't think it's worth modifying
the
language syntax for. I agree that in a loosely typed language that sort
of
thing needs to be checked by the application code anyway.

The difference is that typehinting works this way:
1. I'm a library, I want to get type X for $foo
2. I put typehint, so I didn't need to check if $foo is X
3. If you pass not X to $foo, my code is going to tell you that you
can't do that

And return type works like that:
1. I'm a library writer that says foo() returns X
2. I have to use for it, since I don't use foo()
3. You're client, so you read the docs and see foo() returns X
4. You write code which supposes foo() always returns X
5. I decide these return types are more trouble than they are worth, and
make foo() return false on error, removing return type.
6. Your code has no way to check I did that, so it's broken now.

Basically, it sums up to documentation - if documentation isn't right
(or if it changed and you didn't follow) your code is going to break and
you have no way to prevent it. That's what you have now with @return -
why add language construct?
If it was up to me, I'd probably not bother adding input typehints
either :) But as I said above, input typehints are significantly
different from return types.

I see your point, but maybe I didn't explain myself well enough.

Take the example of an interface. Interfaces aren't directly accessible
(callable), they don't have any functional code in them. So why have them?
What is the single best advantage of an interface, especially in a very
large organization? It ensures consistency.

Take PDO for instance. They are a perfect candidate for interfaces. The
actual implementation of the close() method will differ based on the RDBMS,
but functionally, to the end-developer, they are the same. It closes the
database connection. Once a class implements an interface, and the
end-developer knows this, they don't have to worry about the name of the
method that closes the connection. Also, if the lead architect decides that
there must be a method called foo() in each of the given libs, he/she needs
only to enforce this through the interface, which is implemented by each
class! This can also assist in debugging.

I understand that there's a real difference between type-hinting return
values and parameters, but reverting back to the interface practice, why not
depend on the developer to add a new form of documentation to "promise" to
implement certain methods?

Will


-----Original Message-----
From: Stanislav Malyshev
Sent: Sunday, July 29, 2007 3:07 AM
To: Will Fitch
Cc: 'Jeremy Privett'; 'Larry Garfield'; internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Type-hinted return values in PHP5?
The difference is that typehinting works this way:
1. I'm a library, I want to get type X for $foo
2. I put typehint, so I didn't need to check if $foo is X
3. If you pass not X to $foo, my code is going to tell you that you
can't do that

And return type works like that:
1. I'm a library writer that says foo() returns X
2. I have to use for it, since I don't use foo()
3. You're client, so you read the docs and see foo() returns X
4. You write code which supposes foo() always returns X
5. I decide these return types are more trouble than they are worth, and
make foo() return false on error, removing return type.
6. Your code has no way to check I did that, so it's broken now.

Basically, it sums up to documentation - if documentation isn't right
(or if it changed and you didn't follow) your code is going to break and
you have no way to prevent it. That's what you have now with @return -
why add language construct?
If it was up to me, I'd probably not bother adding input typehints
either :) But as I said above, input typehints are significantly
different from return types.

PHPDoc does that with @return tag.

True but there will be times when the documentation is wrong[1] or when
the function returns something that it shouldn't.

Again, this really has little to do with IDEs. It is aimed improving the
interface language construct.

[1]http://bugs.php.net/bug.php?id=38402

That is true, there is absolutely no reason to say "I'm going to return
only type X so I'm making restriction for myself to return only type X".
However, this feature is geared towards interfaces, so that statement
becomes "Any interface that implements me must provide a method X that
takes Y as input and must return Z".