FAQ
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

Search Discussions

  • David Duong at Jul 18, 2007 at 7:44 pm
    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
  • Troels knak-nielsen at Jul 18, 2007 at 7:56 pm

    On 7/18/07, David Duong 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 Schlüter at Jul 19, 2007 at 2:06 am

    On Wed, 2007-07-18 at 21:55 +0200, troels knak-nielsen wrote:
    On 7/18/07, David Duong 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 at Jul 19, 2007 at 5:51 pm

    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 at Jul 27, 2007 at 10:57 pm
    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:
    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 at Jul 28, 2007 at 11:47 pm

    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 at Jul 29, 2007 at 12:05 am

    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 at Jul 29, 2007 at 12:20 am
    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?
    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 at Jul 29, 2007 at 1:07 am
    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?
    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 at Jul 29, 2007 at 8:07 am

    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
  • Will Fitch at Jul 29, 2007 at 3:42 pm
    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?
    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 at Jul 29, 2007 at 7:58 am

    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 at Jul 30, 2007 at 3:44 pm

    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 at Jul 30, 2007 at 3:38 pm

    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".

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedJul 17, '07 at 4:26p
activeJul 30, '07 at 3:44p
posts15
users7
websitephp.net

People

Translate

site design / logo © 2022 Grokbase