# Type-hinted return values in PHP5? - Thread: https://externals.io/message/31006 - Original archive: https://news-web.php.net/php.internals/31006 - Started by David Duong on 2007-07-17T16:26:18+00:00 - Messages: 15 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #31006 — David Duong — 2007-07-17T16:26:18+00:00 URL: https://externals.io/message/31006#31006 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 --- ## #31063 — David Duong — 2007-07-18T19:44:43+00:00 URL: https://externals.io/message/31006#31063 · In reply to: #31006 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: > 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 --- ## #31064 — troels knak-nielsen — 2007-07-18T19:55:57+00:00 URL: https://externals.io/message/31006#31064 · In reply to: #31063 > 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 --- ## #31071 — johannes@php.net — 2007-07-19T02:04:52+00:00 URL: https://externals.io/message/31006#31071 · In reply to: #31064 > > > […] > > 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 --- ## #31107 — Stanislav Malyshev — 2007-07-19T17:51:42+00:00 URL: https://externals.io/message/31006#31107 · In reply to: #31064 > 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 --- ## #31306 — David Duong — 2007-07-27T22:57:19+00:00 URL: https://externals.io/message/31006#31306 · In reply to: #31107 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: > > […] > > 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. --- ## #31307 — Stanislav Malyshev — 2007-07-28T23:47:34+00:00 URL: https://externals.io/message/31006#31307 · In reply to: #31306 > 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 --- ## #31308 — Larry Garfield — 2007-07-29T00:05:27+00:00 URL: https://externals.io/message/31006#31308 · In reply to: #31307 > > […] > > 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. -- 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 --- ## #31309 — Jeremy Privett — 2007-07-29T00:20:47+00:00 URL: https://externals.io/message/31006#31309 · In reply to: #31308 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? > > […] instead of > > […] would > > […] be > > […] instead > > […] be > > […] 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. > > > […] it > > […] > > 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 --- ## #31310 — Will Fitch — 2007-07-29T01:00:52+00:00 URL: https://externals.io/message/31006#31310 · In reply to: #31309 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? > > […] instead of > > […] would > > […] be > > […] instead > > […] be > > […] 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. > > > […] it > > […] > > 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 --- ## #31311 — Stanislav Malyshev — 2007-07-29T07:58:33+00:00 URL: https://externals.io/message/31006#31311 · In reply to: #31308 > 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 --- ## #31312 — Stanislav Malyshev — 2007-07-29T08:06:51+00:00 URL: https://externals.io/message/31006#31312 · In reply to: #31310 > 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 --- ## #31313 — Will Fitch — 2007-07-29T15:42:25+00:00 URL: https://externals.io/message/31006#31313 · In reply to: #31312 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 [mailto:stas@zend.com] 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? > 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 --- ## #31323 — David Duong — 2007-07-30T15:38:12+00:00 URL: https://externals.io/message/31006#31323 · In reply to: #31307 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. 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". --- ## #31324 — David Duong — 2007-07-30T15:44:12+00:00 URL: https://externals.io/message/31006#31324 · In reply to: #31311 Stanislav Malyshev wrote: > > […] > > 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