Type-hinted return values in PHP5?

php.internals

David Duong

19 years ago
Hello everyone, I'm emailing to this list to suggest that "support for type-hinted return values"[1] be in added in PHP 5.y.x instead of PHP 6. Conceptually, this is the second half of "type-hints" already introduced in PHP 5. This is why: When a programmer is designing an interface (the language construct), only what is accepted by the interface can be defined. Calling code is left with no idea of what the return type is going to be. Even with great documentation, when designing an interface, it would be great to be able to take the responsibility of type checking return values from calling code onto the interface. To design a full interface, the interface designer should be able to say that a caller can call method X with input types Y and Z, then expect an object that implements interface Z to be returned. The caller should not have the responsibility of handling any other return types. I'm looking forward to many of the upcoming features of PHP6, but PHP 6 is far from being stable (?). This is a change will break any existing code and is not a big extension on how PHP, a weakly typed language (not necessarily a bad thing), handles types. [1] http://oss.backendmedia.com/PhP60 ps - please let me know if posts like these should be posted elsewhere Thanks, David N. Q. Duong

David Duong

19 years ago
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:

troels knak-nielsen

19 years ago
On 7/18/07, David Duong <david.nqd@gmail.com> wrote:
> Since there isn't any comments on this, should I have posted this > elsewhere? or is it just that no one is interested?
It could be interesting to know, if the reason why this hasn't been implemented already, is technical one, or a design decision?
-- troels

Johannes Schlueter

19 years ago
On Wed, 2007-07-18 at 21:55 +0200, troels knak-nielsen wrote:
> On 7/18/07, David Duong <david.nqd@gmail.com> wrote: > > Since there isn't any comments on this, should I have posted this > > elsewhere? or is it just that no one is interested? > > 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

Stanislav Malyshev

19 years ago
> It could be interesting to know, if the reason why this hasn't been > implemented already, is technical one, or a design decision?
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.
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

David Duong

19 years ago
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:

Stanislav Malyshev

19 years ago
> 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.
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.
> If I, or someone else decided to make a patch for this, and assuming it > worked exactly like I described, would it be accepted?
I don't know... I personally don't see much use for it, but others may disagree.
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Larry Garfield

19 years ago
On Saturday 28 July 2007, Stanislav Malyshev wrote:
> > 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. > > 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. > > > If I, or someone else decided to make a patch for this, and assuming it > > worked exactly like I described, would it be accepted? > > 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.
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

Jeremy Privett

19 years ago
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 [mailto:larry@garfieldtech.com] Sent: Saturday, July 28, 2007 6:05 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] Re: Type-hinted return values in PHP5? On Saturday 28 July 2007, Stanislav Malyshev wrote:
> > 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.
> > 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. > > > If I, or someone else decided to make a patch for this, and assuming
it
> > worked exactly like I described, would it be accepted? > > 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.
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Will Fitch

19 years ago
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 [mailto:jeremy@peak8solutions.com] 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 [mailto:larry@garfieldtech.com] Sent: Saturday, July 28, 2007 6:05 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] Re: Type-hinted return values in PHP5? On Saturday 28 July 2007, Stanislav Malyshev wrote:
> > 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.
> > 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. > > > If I, or someone else decided to make a patch for this, and assuming
it
> > worked exactly like I described, would it be accepted? > > 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.
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Stanislav Malyshev

19 years ago
> 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.
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 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
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.
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Stanislav Malyshev

19 years ago
> I think the only serious advantage I could see would be to allow > context-assistance IDEs more data, so they could provide method-completion.
PHPDoc does that with @return tag.
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

David Duong

19 years ago
Stanislav Malyshev wrote:
>> I think the only serious advantage I could see would be to allow >> context-assistance IDEs more data, so they could provide >> method-completion. > > 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

David Duong

19 years ago
Stanislav Malyshev wrote:
>> 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. > > 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. > >> If I, or someone else decided to make a patch for this, and assuming >> it worked exactly like I described, would it be accepted? > > I don't know... I personally don't see much use for it, but others may > disagree.
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".