FAQ
Attached is my return type hinting patch. It allows type hinting for
parameters and return values. Int, float, bool, string, num, scalar,
resource, object, array, and class names are supported for both
parameters and return values. Objects with __toString methods are
allowed to pass for scalar and string type hints.

function myTypedFunction returns int(string $stuff, bool, $things, num
$amount) {
return 'This will cause an error.'
}

I want to move the returns clause after the parameter list, but I
couldn't get it to work in the parser:

function x($param) returns y {
return new y
}

Parameters and return values are strict. Int means int (to the type),
etc. For type hinted parameters, null is allowed only if it is the
default value.

Implementations of abstract functions must be compatible both in their
parameter and return types. Mismatched types will cause an error.

Note: The parameter type hinting is complete. The return type hinting
works, but there is a small memory leak which I do not know how to fix.
Besides that it's running perfectly, it's very minor obstacle, I'm just
not familiar enough with C to fix this right now.

Search Discussions

  • Stanislav Malyshev at Apr 25, 2008 at 5:07 pm
    Hi!

    In general, it'd be very nice to have some definition of the proposed
    feature beyond the patch. It would probably answer some of my questions
    that follow :)
    parameters and return values. Objects with __toString methods are
    allowed to pass for scalar and string type hints.
    What about objects that can be converted to other types (cast_object
    handler)?
    function myTypedFunction returns int(string $stuff, bool, $things, num
    $amount) {
    return 'This will cause an error.'
    }
    What about return "1"? Also I notice it introduces new keyword -
    returns. Is it necessary? Each new keyword means broken code.
    Parameters and return values are strict. Int means int (to the type),
    Meaning that int would reject 1.0, true and "1"? bool would reject 1 and
    0 and null? Ouch, ouch, ouch.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Sam Barrow at Apr 25, 2008 at 5:58 pm

    On Fri, 2008-04-25 at 10:06 -0700, Stanislav Malyshev wrote:
    Hi!

    In general, it'd be very nice to have some definition of the proposed
    feature beyond the patch. It would probably answer some of my questions
    that follow :)
    parameters and return values. Objects with __toString methods are
    allowed to pass for scalar and string type hints.
    What about objects that can be converted to other types (cast_object
    handler)?
    Hadn't thought about these, don't see why it couldn't be added though.
    function myTypedFunction returns int(string $stuff, bool, $things, num
    $amount) {
    return 'This will cause an error.'
    }
    What about return "1"? Also I notice it introduces new keyword -
    returns. Is it necessary? Each new keyword means broken code.
    We could probably find a way to use the return keyword or another
    syntax, I just did it like this for simplicity.
    Parameters and return values are strict. Int means int (to the type),
    Meaning that int would reject 1.0, true and "1"? bool would reject 1 and
    0 and null? Ouch, ouch, ouch.
    As it is now, yes, this works just like parameter hints. Could be
    changed if decided upon.
  • Sam Barrow at Apr 25, 2008 at 6:19 pm

    On Fri, 2008-04-25 at 10:06 -0700, Stanislav Malyshev wrote:
    I notice it introduces new keyword -
    returns. Is it necessary? Each new keyword means broken code.
    I have adapted the patch to reuse the "return" keyword.
  • Sam Barrow at Apr 25, 2008 at 6:19 pm
    Can anyone help me with this?

    Here is the current function declaration rule:
    T_FUNCTION { $1.u.opline_num = CG(zend_lineno); } is_reference T_STRING
    optional_function_return_type { zend_do_begin_function_declaration(&$1,
    &$4, 0, $3.op_type, NULL, &$5 TSRMLS_CC); } '(' parameter_list ')' '{'
    inner_statement_list '}' { zend_do_end_function_declaration(&$1
    TSRMLS_CC); }

    I want to move "optional_function_return_type" AFTER the parameter list,
    but I also need to pass it to zend_do_begin_function_declaration. Is
    this even possible?

    What I'm trying to acheive is this:

    function a($arg1, $arg2) return int {
    }

    Currently:

    function a return int($arg1, $arg2) {
    }
    On Fri, 2008-04-25 at 11:30 -0400, Sam Barrow wrote:
    Attached is my return type hinting patch. It allows type hinting for
    parameters and return values. Int, float, bool, string, num, scalar,
    resource, object, array, and class names are supported for both
    parameters and return values. Objects with __toString methods are
    allowed to pass for scalar and string type hints.

    function myTypedFunction returns int(string $stuff, bool, $things, num
    $amount) {
    return 'This will cause an error.'
    }

    I want to move the returns clause after the parameter list, but I
    couldn't get it to work in the parser:

    function x($param) returns y {
    return new y
    }

    Parameters and return values are strict. Int means int (to the type),
    etc. For type hinted parameters, null is allowed only if it is the
    default value.

    Implementations of abstract functions must be compatible both in their
    parameter and return types. Mismatched types will cause an error.

    Note: The parameter type hinting is complete. The return type hinting
    works, but there is a small memory leak which I do not know how to fix.
    Besides that it's running perfectly, it's very minor obstacle, I'm just
    not familiar enough with C to fix this right now.

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Alain Williams at Apr 25, 2008 at 6:23 pm

    On Fri, Apr 25, 2008 at 02:16:02PM -0400, Sam Barrow wrote:

    Can anyone help me with this?

    Here is the current function declaration rule:
    T_FUNCTION { $1.u.opline_num = CG(zend_lineno); } is_reference T_STRING
    optional_function_return_type { zend_do_begin_function_declaration(&$1,
    &$4, 0, $3.op_type, NULL, &$5 TSRMLS_CC); } '(' parameter_list ')' '{'
    inner_statement_list '}' { zend_do_end_function_declaration(&$1
    TSRMLS_CC); }

    I want to move "optional_function_return_type" AFTER the parameter list,
    but I also need to pass it to zend_do_begin_function_declaration. Is
    this even possible?

    What I'm trying to acheive is this:

    function a($arg1, $arg2) return int {
    }

    Currently:

    function a return int($arg1, $arg2) {
    }
    Why note the following (which would be more C like):

    function return int a($arg1, $arg2) {
    }


    --
    Alain Williams
    Linux 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
    Chairman of UKUUG: http://www.ukuug.org/
    #include <std_disclaimer.h>
  • Sam Barrow at Apr 25, 2008 at 6:28 pm

    Why note the following (which would be more C like):

    function return int a($arg1, $arg2) {
    }
    It gets a little long when you're using classes

    abstract protected function return int dostuff() {

    }

    vs

    abstract protected function dostuff() return int {

    }
  • Stanislav Malyshev at Apr 25, 2008 at 6:32 pm
    Hi!
    Why note the following (which would be more C like):

    function return int a($arg1, $arg2) {
    }
    In C I am familiar with "return" keyword is never used in function
    definition.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Sam Barrow at Apr 25, 2008 at 6:47 pm
    I figured it out, the syntax is now as follows:

    function a($b, $c) returns d {
    }

    I'll post an update soon.
  • Jeremy Privett at Apr 25, 2008 at 7:08 pm

    Sam Barrow wrote:
    I figured it out, the syntax is now as follows:

    function a($b, $c) returns d {
    }

    I'll post an update soon.

    That's certainly a non-intuitive syntax. How about we take a page out of
    the book of other C-style languages before trying to invent something
    else? I agree with Stas, "return" and "returns" are not part of a
    function definition.

    --
    Jeremy Privett
    C.E.O. & C.S.A.
    Omega Vortex Corporation

    http://www.omegavortex.net

    Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation.
  • Sam Barrow at Apr 25, 2008 at 7:18 pm

    On Fri, 2008-04-25 at 14:08 -0500, Jeremy Privett wrote:
    Sam Barrow wrote:
    I figured it out, the syntax is now as follows:

    function a($b, $c) returns d {
    }

    I'll post an update soon.

    That's certainly a non-intuitive syntax. How about we take a page out of
    the book of other C-style languages before trying to invent something
    else? I agree with Stas, "return" and "returns" are not part of a
    function definition.
    I don't think it's non-intuitive at all, and even so, it's the most intuitive we have. This ordering makes more sense to me at first glance (in the order I would think about things; scope, name, arguments, return).
  • Nathan Nobbe at Apr 25, 2008 at 7:25 pm

    On Fri, Apr 25, 2008 at 1:15 PM, Sam Barrow wrote:
    On Fri, 2008-04-25 at 14:08 -0500, Jeremy Privett wrote:
    Sam Barrow wrote:
    I figured it out, the syntax is now as follows:

    function a($b, $c) returns d {
    }

    I'll post an update soon.

    That's certainly a non-intuitive syntax. How about we take a page out of
    the book of other C-style languages before trying to invent something
    else? I agree with Stas, "return" and "returns" are not part of a
    function definition.
    I don't think it's non-intuitive at all, and even so, it's the most
    intuitive we have. This ordering makes more sense to me at first glance (in
    the order I would think about things; scope, name, arguments, return).

    im not sure the following has been explicitly proposed, but how about
    omitting the 'return' keyword and placing the return type hint before the
    function identifier

    function int a($b, $c) {}

    i think that is most congruent with 'typical' of c style languages, no ?

    -nathan
  • Sam Barrow at Apr 25, 2008 at 7:28 pm

    On Fri, 2008-04-25 at 13:24 -0600, Nathan Nobbe wrote:
    On Fri, Apr 25, 2008 at 1:15 PM, Sam Barrow wrote:
    On Fri, 2008-04-25 at 14:08 -0500, Jeremy Privett wrote:
    Sam Barrow wrote:
    I figured it out, the syntax is now as follows:

    function a($b, $c) returns d {
    }

    I'll post an update soon.

    That's certainly a non-intuitive syntax. How about we take a
    page out of
    the book of other C-style languages before trying to invent something
    else? I agree with Stas, "return" and "returns" are not part of a
    function definition.

    I don't think it's non-intuitive at all, and even so, it's the
    most intuitive we have. This ordering makes more sense to me
    at first glance (in the order I would think about things;
    scope, name, arguments, return).

    im not sure the following has been explicitly proposed, but how about
    omitting the 'return' keyword and placing the return type hint before
    the function identifier

    function int a($b, $c) {}
    This is, but I don't think this is possible, due to confusion with the
    keywords (public, private, static, abstract, etc). Plus this leads to
    long strings of keywords.
    i think that is most congruent with 'typical' of c style languages,
    no ?

    -nathan
  • Chris Stockton at Apr 25, 2008 at 9:22 pm

    On Fri, Apr 25, 2008 at 12:25 PM, Sam Barrow wrote:
    On Fri, 2008-04-25 at 13:24 -0600, Nathan Nobbe wrote:
    On Fri, Apr 25, 2008 at 1:15 PM, Sam Barrow wrote:
    On Fri, 2008-04-25 at 14:08 -0500, Jeremy Privett wrote:
    Sam Barrow wrote:
    I figured it out, the syntax is now as follows:

    function a($b, $c) returns d {
    }

    I'll post an update soon.

    That's certainly a non-intuitive syntax. How about we take a
    page out of
    the book of other C-style languages before trying to invent something
    else? I agree with Stas, "return" and "returns" are not part of a
    function definition.

    I don't think it's non-intuitive at all, and even so, it's the
    most intuitive we have. This ordering makes more sense to me
    at first glance (in the order I would think about things;
    scope, name, arguments, return).

    im not sure the following has been explicitly proposed, but how about
    omitting the 'return' keyword and placing the return type hint before
    the function identifier

    function int a($b, $c) {}
    This is, but I don't think this is possible, due to confusion with the
    keywords (public, private, static, abstract, etc). Plus this leads to
    long strings of keywords.

    There can be no technical reason why this more adopted and understood syntax
    should not be possible. Adding returns as a keyword would completely break
    tons of code. Why are the proposals on something that is so consistent
    across many languages being changed so obscurely? Why a seperate
    non-intuitive syntax.

    public function int (string $foo) { return 1; }

    Can't we keep the sanity?

    [ ... ] Plus this leads to
    long strings of keywords.

    Are you kidding? strlen('returns int') > strlen('int'); .....

    -Chris
  • Sam Barrow at Apr 25, 2008 at 10:04 pm
    I don't know, maybe it does work. But either way I'm not introducing a
    new keyword, I changed the patch to reuse the return keyword.

    Yes, long strings of keywords:

    abstract protected string function dostuff()
    On Fri, 2008-04-25 at 14:22 -0700, Chris Stockton wrote:
    On Fri, Apr 25, 2008 at 12:25 PM, Sam Barrow wrote:
    On Fri, 2008-04-25 at 13:24 -0600, Nathan Nobbe wrote:
    On Fri, Apr 25, 2008 at 1:15 PM, Sam Barrow wrote:
    On Fri, 2008-04-25 at 14:08 -0500, Jeremy Privett
    wrote:
    Sam Barrow wrote:
    I figured it out, the syntax is now as follows:

    function a($b, $c) returns d {
    }

    I'll post an update soon.

    That's certainly a non-intuitive syntax. How about
    we take a
    page out of
    the book of other C-style languages before trying
    to invent
    something
    else? I agree with Stas, "return" and "returns"
    are not part
    of a
    function definition.

    I don't think it's non-intuitive at all, and even
    so, it's the
    most intuitive we have. This ordering makes more
    sense to me
    at first glance (in the order I would think about things;
    scope, name, arguments, return).

    im not sure the following has been explicitly proposed, but how about
    omitting the 'return' keyword and placing the return type
    hint before
    the function identifier

    function int a($b, $c) {}

    This is, but I don't think this is possible, due to confusion
    with the
    keywords (public, private, static, abstract, etc). Plus this
    leads to
    long strings of keywords.

    There can be no technical reason why this more adopted and understood
    syntax should not be possible. Adding returns as a keyword would
    completely break tons of code. Why are the proposals on something that
    is so consistent across many languages being changed so obscurely? Why
    a seperate non-intuitive syntax.

    public function int (string $foo) { return 1; }

    Can't we keep the sanity?


    [ ... ] Plus this leads to
    long strings of keywords.

    Are you kidding? strlen('returns int') > strlen('int'); .....


    -Chris
  • Chris Stockton at Apr 25, 2008 at 10:15 pm
    Hello Sam,

    I think you misunderstand, let me retype for you.

    strlen('abstract protected function string dostuff()') < strlen('abstract
    protected function dostuff() return string')

    Making your argument on length void, also, maybe we should not base a
    language change decision on typing extra characters..

    Sorry man, but to me the code below looks so unusual for what it is meant to
    represent:

    abstract protected function bar($foo) return string {
    // code
    }

    The above, actually kind of makes me think something non-conventional is
    going to happen like return string specifies that it will be auto type
    casted to a string for me or something. like:

    abstract protected function bar($foo) return string {
    return $foo;
    // is auto magically like: return (string) $foo;
    }

    vs the below code that tells me function returns a string like in many
    popular languages.
    abstract protected function string bar($foo) {
    return (string) $foo;
    }

    -Chris
    On Fri, Apr 25, 2008 at 3:04 PM, Sam Barrow wrote:

    I don't know, maybe it does work. But either way I'm not introducing a
    new keyword, I changed the patch to reuse the return keyword.

    Yes, long strings of keywords:

    abstract protected string function dostuff()
    On Fri, 2008-04-25 at 14:22 -0700, Chris Stockton wrote:
    On Fri, Apr 25, 2008 at 12:25 PM, Sam Barrow <sam@sambarrow.com>
    wrote:
    On Fri, 2008-04-25 at 13:24 -0600, Nathan Nobbe wrote:
    On Fri, Apr 25, 2008 at 1:15 PM, Sam Barrow wrote:
    On Fri, 2008-04-25 at 14:08 -0500, Jeremy Privett
    wrote:
    Sam Barrow wrote:
    I figured it out, the syntax is now as follows:

    function a($b, $c) returns d {
    }

    I'll post an update soon.

    That's certainly a non-intuitive syntax. How about
    we take a
    page out of
    the book of other C-style languages before trying
    to invent
    something
    else? I agree with Stas, "return" and "returns"
    are not part
    of a
    function definition.

    I don't think it's non-intuitive at all, and even
    so, it's the
    most intuitive we have. This ordering makes more
    sense to me
    at first glance (in the order I would think about things;
    scope, name, arguments, return).

    im not sure the following has been explicitly proposed, but how about
    omitting the 'return' keyword and placing the return type
    hint before
    the function identifier

    function int a($b, $c) {}

    This is, but I don't think this is possible, due to confusion
    with the
    keywords (public, private, static, abstract, etc). Plus this
    leads to
    long strings of keywords.

    There can be no technical reason why this more adopted and understood
    syntax should not be possible. Adding returns as a keyword would
    completely break tons of code. Why are the proposals on something that
    is so consistent across many languages being changed so obscurely? Why
    a seperate non-intuitive syntax.

    public function int (string $foo) { return 1; }

    Can't we keep the sanity?


    [ ... ] Plus this leads to
    long strings of keywords.

    Are you kidding? strlen('returns int') > strlen('int'); .....


    -Chris
  • Alain Williams at Apr 25, 2008 at 11:13 pm
    public function int doThing(string $foo) { return 1; }

    The above is the best (ie omit 'return' or 'returns').

    This also is consistent with C and with the way that the manual is written, eg:

    http://www.php.net/manual/en/function.strlen.php

    The only argument is the relative ordering of the keywords.
    We keep 'function' - since that is the way that the language works.
    Things like 'public' we put before 'function' since that is the way that
    it works in PHP 5 objects.

    So the only thing to decide is where the type goes:

    public function int doThing(string $foo) { return 1; }

    or:

    public int function doThing(string $foo) { return 1; }

    I would favour the first one, this is probably also easier to parse, as
    following 'function' and before '(' you can have:

    * 1 word - which must be the name of the function
    * 2 words - the first word is the return type, the second the function name.

    If the function returns a reference to something of a particular type, where
    does the '&' go:

    public function &int doThing(string $foo) { return 1; }

    or:

    public function int& doThing(string $foo) { return 1; }

    I would suggest the second, ie just before the function name.

    --
    Alain Williams
    Linux 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
    Chairman of UKUUG: http://www.ukuug.org/
    #include <std_disclaimer.h>
  • Sam Barrow at Apr 26, 2008 at 8:01 am
    I like the first too, if this can be implemented I think it is a
    suitable syntax.
    On Sat, 2008-04-26 at 00:13 +0100, Alain Williams wrote:
    public function int doThing(string $foo) { return 1; }

    The above is the best (ie omit 'return' or 'returns').

    This also is consistent with C and with the way that the manual is written, eg:

    http://www.php.net/manual/en/function.strlen.php

    The only argument is the relative ordering of the keywords.
    We keep 'function' - since that is the way that the language works.
    Things like 'public' we put before 'function' since that is the way that
    it works in PHP 5 objects.

    So the only thing to decide is where the type goes:

    public function int doThing(string $foo) { return 1; }

    or:

    public int function doThing(string $foo) { return 1; }

    I would favour the first one, this is probably also easier to parse, as
    following 'function' and before '(' you can have:

    * 1 word - which must be the name of the function
    * 2 words - the first word is the return type, the second the function name.

    If the function returns a reference to something of a particular type, where
    does the '&' go:

    public function &int doThing(string $foo) { return 1; }

    or:

    public function int& doThing(string $foo) { return 1; }

    I would suggest the second, ie just before the function name.

    --
    Alain Williams
    Linux 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
    Chairman of UKUUG: http://www.ukuug.org/
    #include <std_disclaimer.h>
  • David Zülke at Apr 26, 2008 at 6:06 pm
    Wouldn't the most consistent way be to omit "function" altogether when
    using a return type hint?

    public static function zomg() {
    return $somethingArbitrary;
    }

    public static string foo() {
    return $mustBeString;
    }

    otoh, should there ever be a type "function" (e.g. for anonymous
    funcs) down the road, that'd mean trouble ;)

    David



    Am 26.04.2008 um 01:13 schrieb Alain Williams:
    public function int doThing(string $foo) { return 1; }

    The above is the best (ie omit 'return' or 'returns').

    This also is consistent with C and with the way that the manual is
    written, eg:

    http://www.php.net/manual/en/function.strlen.php

    The only argument is the relative ordering of the keywords.
    We keep 'function' - since that is the way that the language works.
    Things like 'public' we put before 'function' since that is the way
    that
    it works in PHP 5 objects.

    So the only thing to decide is where the type goes:

    public function int doThing(string $foo) { return 1; }

    or:

    public int function doThing(string $foo) { return 1; }

    I would favour the first one, this is probably also easier to parse,
    as
    following 'function' and before '(' you can have:

    * 1 word - which must be the name of the function
    * 2 words - the first word is the return type, the second the
    function name.

    If the function returns a reference to something of a particular
    type, where
    does the '&' go:

    public function &int doThing(string $foo) { return 1; }

    or:

    public function int& doThing(string $foo) { return 1; }

    I would suggest the second, ie just before the function name.

    --
    Alain Williams
    Linux 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
    Chairman of UKUUG: http://www.ukuug.org/
    #include <std_disclaimer.h>

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Nathan Nobbe at Apr 26, 2008 at 10:24 pm

    On Sat, Apr 26, 2008 at 2:06 PM, David Zülke wrote:

    Wouldn't the most consistent way be to omit "function" altogether when
    using a return type hint?

    public static function zomg() {
    return $somethingArbitrary;
    }

    public static string foo() {
    return $mustBeString;
    }
    i think leaving 'function' in there makes sense because thats the way php
    currently works.

    otoh, should there ever be a type "function" (e.g. for anonymous funcs) down
    the road, that'd mean trouble ;)

    wow; good point! maybe if anonymous functions are ever supported the type
    could be capitalized as in 'Function'

    public function Function doStuff() {
    return function() {}
    }

    -nathan
  • David Zülke at Apr 26, 2008 at 11:26 pm

    Am 27.04.2008 um 00:24 schrieb Nathan Nobbe:
    On Sat, Apr 26, 2008 at 2:06 PM, David Zülke wrote:

    Wouldn't the most consistent way be to omit "function" altogether
    when
    using a return type hint?

    public static function zomg() {
    return $somethingArbitrary;
    }

    public static string foo() {
    return $mustBeString;
    }
    i think leaving 'function' in there makes sense because thats the
    way php
    currently works.
    Well that was my point. Functions without return type hints use
    "function", to indicate that they are generic in this respect, and
    functions/methods with a type hint omit it to signal the difference.
    Having both would be redundant. But then...:

    otoh, should there ever be a type "function" (e.g. for anonymous
    funcs) down
    the road, that'd mean trouble ;)

    wow; good point! maybe if anonymous functions are ever supported
    the type
    could be capitalized as in 'Function'

    public function Function doStuff() {
    return function() {}
    }

    Absolutely not. Right now, all PHP native types are lowercase. Can't
    see why anon functions should be different.

    Actually, both ways have problems:

    public function gimmeThat() {
    return function() { echo 'yay'; }
    }

    is ambiguous if return type hints require omitting "function", and

    public function function gimmeThat() {
    ...
    }

    is just plain ugly.

    So maybe anon funcs should have a different type name :p


    David
  • Chris Stockton at Apr 27, 2008 at 12:11 am
    *cough* lambda *cough*
    On Sat, Apr 26, 2008 at 4:26 PM, David Zülke wrote:

    Am 27.04.2008 um 00:24 schrieb Nathan Nobbe:
    On Sat, Apr 26, 2008 at 2:06 PM, David Zülke wrote:

    Wouldn't the most consistent way be to omit "function" altogether when
    using a return type hint?

    public static function zomg() {
    return $somethingArbitrary;
    }

    public static string foo() {
    return $mustBeString;
    }
    i think leaving 'function' in there makes sense because thats the way
    php
    currently works.
    Well that was my point. Functions without return type hints use
    "function", to indicate that they are generic in this respect, and
    functions/methods with a type hint omit it to signal the difference. Having
    both would be redundant. But then...:


    otoh, should there ever be a type "function" (e.g. for anonymous funcs)
    down
    the road, that'd mean trouble ;)

    wow; good point! maybe if anonymous functions are ever supported the
    type
    could be capitalized as in 'Function'

    public function Function doStuff() {
    return function() {}
    }

    Absolutely not. Right now, all PHP native types are lowercase. Can't see
    why anon functions should be different.

    Actually, both ways have problems:

    public function gimmeThat() {
    return function() { echo 'yay'; }
    }

    is ambiguous if return type hints require omitting "function", and

    public function function gimmeThat() {
    ...
    }

    is just plain ugly.

    So maybe anon funcs should have a different type name :p


    David

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • David Zülke at Apr 27, 2008 at 12:20 am
    But anonymous functions and lambda expressions are not the same thing...


    David



    Am 27.04.2008 um 02:11 schrieb Chris Stockton:
    *cough* lambda *cough*

    On Sat, Apr 26, 2008 at 4:26 PM, David Zülke wrote:
    Am 27.04.2008 um 00:24 schrieb Nathan Nobbe:


    On Sat, Apr 26, 2008 at 2:06 PM, David Zülke wrote:

    Wouldn't the most consistent way be to omit "function" altogether when
    using a return type hint?

    public static function zomg() {
    return $somethingArbitrary;
    }

    public static string foo() {
    return $mustBeString;
    }


    i think leaving 'function' in there makes sense because thats the
    way php
    currently works.

    Well that was my point. Functions without return type hints use
    "function", to indicate that they are generic in this respect, and
    functions/methods with a type hint omit it to signal the difference.
    Having both would be redundant. But then...:



    otoh, should there ever be a type "function" (e.g. for anonymous
    funcs) down
    the road, that'd mean trouble ;)


    wow; good point! maybe if anonymous functions are ever supported
    the type
    could be capitalized as in 'Function'

    public function Function doStuff() {
    return function() {}
    }


    Absolutely not. Right now, all PHP native types are lowercase. Can't
    see why anon functions should be different.

    Actually, both ways have problems:

    public function gimmeThat() {
    return function() { echo 'yay'; }
    }

    is ambiguous if return type hints require omitting "function", and

    public function function gimmeThat() {
    ...
    }

    is just plain ugly.

    So maybe anon funcs should have a different type name :p


    David

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Chris Stockton at Apr 27, 2008 at 2:00 am
    Anonymous functions as you know them today come from lambda calculus which
    was created before computers were even made. Generally it is agreed anon
    func == labmda can be used interchangeably.

    Most developers will understand what:
    public function lambda sowat () { return function OR lambda, whatever () { }
    }

    Seems more natural then whatever nightmare people could think of, like
    public function Function or public function ANONFUNCLOL...

    The thing that I hate about that idea is not a reserved word, any there is
    surely plenty of people with functions named them. Perhaps that detail can
    be worked out in the grammar without breaking bc.

    -Chris
    On Sat, Apr 26, 2008 at 5:20 PM, David Zülke wrote:

    But anonymous functions and lambda expressions are not the same thing...
  • Alain Williams at Apr 27, 2008 at 9:22 am

    On Sat, Apr 26, 2008 at 05:11:29PM -0700, Chris Stockton wrote:
    *cough* lambda *cough*
    That would be nice, but the scoping of variables in PHP doesn't seem to
    make that nice, the code below results in '' Undefined variable: aa ''
    if I take the 'global' statement out, if I leave it in the echo in b()
    shows it as the empty string.

    Getting this right would be nice as it would allow (what has been explained
    to me at any rate) functional programming if a() returns an anonymous b().
    The stuff below works in perl and python.


    function a($aa) {
    echo "a called aa=$aa\n";
    function b() {
    global $aa;
    echo "in b aa=$aa\n";
    }

    b();
    }

    a('this is aa');

    --
    Alain Williams
    Linux 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
    Chairman of UKUUG: http://www.ukuug.org/
    #include <std_disclaimer.h>
  • Rasmus Lerdorf at Apr 27, 2008 at 7:49 pm

    Alain Williams wrote:
    On Sat, Apr 26, 2008 at 05:11:29PM -0700, Chris Stockton wrote:
    *cough* lambda *cough*
    That would be nice, but the scoping of variables in PHP doesn't seem to
    make that nice, the code below results in '' Undefined variable: aa ''
    if I take the 'global' statement out, if I leave it in the echo in b()
    shows it as the empty string.
    Because aa is not global in your example. Variables are either global
    or function-scoped in PHP. There is no such thing as a context or
    parent scope which is what you are looking for here.
    Getting this right would be nice as it would allow (what has been explained
    to me at any rate) functional programming if a() returns an anonymous b().
    The stuff below works in perl and python.


    function a($aa) {
    echo "a called aa=$aa\n";
    function b() {
    global $aa;
    echo "in b aa=$aa\n";
    }

    b();
    }

    a('this is aa');
  • Larry Garfield at Apr 27, 2008 at 8:23 pm

    On Sunday 27 April 2008, Alain Williams wrote:
    On Sat, Apr 26, 2008 at 05:11:29PM -0700, Chris Stockton wrote:
    *cough* lambda *cough*
    That would be nice, but the scoping of variables in PHP doesn't seem to
    make that nice, the code below results in '' Undefined variable: aa ''
    if I take the 'global' statement out, if I leave it in the echo in b()
    shows it as the empty string.

    Getting this right would be nice as it would allow (what has been explained
    to me at any rate) functional programming if a() returns an anonymous b().
    The stuff below works in perl and python.


    function a($aa) {
    echo "a called aa=$aa\n";
    function b() {
    global $aa;
    echo "in b aa=$aa\n";
    }

    b();
    }

    a('this is aa');
    The suggestion when last this was discussed was to introduce a
    keyword "lexical" that would mean "pull this variable in from the lexical
    parent of this function, with the same semantics as pulling in a global
    variable". Aside from the introduction of another reserved word, it seemed
    like a well-received idea and a good solution.

    --
    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
  • Sam Barrow at Apr 29, 2008 at 3:25 pm
    Well in summation I think this is something that should be implemented,
    I don't see any arguments against implementing this atleast for arrays
    and classes, like we already have for function parameters.

    The only thing left would be to decide on the syntax

    public array function x() { // Probably the easiest
    public array x() { // I like this best, if it's possible
    public function x() return array { // Probably not, just throwing it out
    there

    Agree?
  • Pierre Joye at Apr 29, 2008 at 3:37 pm

    On Tue, Apr 29, 2008 at 5:22 PM, Sam Barrow wrote:
    Well in summation I think this is something that should be implemented,
    I don't see any arguments against implementing this atleast for arrays
    and classes, like we already have for function parameters.

    The only thing left would be to decide on the syntax

    public array function x() { // Probably the easiest
    public array x() { // I like this best, if it's possible
    public function x() return array { // Probably not, just throwing it out
    there

    Agree?

    Again, what's about the well written RFC and patch from RFC? Have you
    contacted him and/or tried to get things done there instead of
    duplicating the discussions, the work and the code?


    Thanks for your work,

    Cheers,
  • Sam Barrow at Apr 29, 2008 at 3:43 pm
    Mine uses less code to accomplish the same thing, doesn't introduce new
    tokens, and has an easier syntax. I'm still working on it, but I can
    give an update in a couple days. I just wanted to see what people
    thought about the implementation aspect of it.
    On Tue, 2008-04-29 at 17:37 +0200, Pierre Joye wrote:
    On Tue, Apr 29, 2008 at 5:22 PM, Sam Barrow wrote:

    Well in summation I think this is something that should be implemented,
    I don't see any arguments against implementing this atleast for arrays
    and classes, like we already have for function parameters.

    The only thing left would be to decide on the syntax

    public array function x() { // Probably the easiest
    public array x() { // I like this best, if it's possible
    public function x() return array { // Probably not, just throwing it out
    there

    Agree?

    Again, what's about the well written RFC and patch from RFC? Have you
    contacted him and/or tried to get things done there instead of
    duplicating the discussions, the work and the code?


    Thanks for your work,

    Cheers,
  • Pierre Joye at Apr 29, 2008 at 3:50 pm

    On Tue, Apr 29, 2008 at 5:40 PM, Sam Barrow wrote:
    Mine uses less code to accomplish the same thing, doesn't introduce new
    tokens, and has an easier syntax.
    Ok, sorry to have tried to get this feature in. I do think that going
    down the way you choosed right now is the best way to forget this
    feature forever.
    I'm still working on it, but I can
    give an update in a couple days. I just wanted to see what people
    thought about the implementation aspect of it.
    The RFC system was proposed exactly for one reason: to avoid dozen pf
    repetitive discussions about the same topic raised every twp weeks on
    internals. But you seem to completely miss it.

    Sorry to have interfered in this thread,

    Cheers,
  • David Zülke at Apr 29, 2008 at 4:00 pm
    As I've pointed out,

    public array x()

    will become ambiguous once we introduce a type "function", which is
    not unlikely at this point


    David





    Am 29.04.2008 um 17:22 schrieb Sam Barrow:
    Well in summation I think this is something that should be
    implemented,
    I don't see any arguments against implementing this atleast for arrays
    and classes, like we already have for function parameters.

    The only thing left would be to decide on the syntax

    public array function x() { // Probably the easiest
    public array x() { // I like this best, if it's possible
    public function x() return array { // Probably not, just throwing it
    out
    there

    Agree?
  • Sam Barrow at Apr 29, 2008 at 4:08 pm
    On Tue, 2008-04-29 at 18:00 +0200, David Zülke wrote:
    As I've pointed out,

    public array x()

    will become ambiguous once we introduce a type "function", which is
    not unlikely at this point
    That's what I thought, that's why I said number 1 is the most likely.
    David





    Am 29.04.2008 um 17:22 schrieb Sam Barrow:
    Well in summation I think this is something that should be
    implemented,
    I don't see any arguments against implementing this atleast for arrays
    and classes, like we already have for function parameters.

    The only thing left would be to decide on the syntax

    public array function x() { // Probably the easiest
    public array x() { // I like this best, if it's possible
    public function x() return array { // Probably not, just throwing it
    out
    there

    Agree?
  • Stanislav Malyshev at Apr 29, 2008 at 4:07 pm
    Hi!
    Well in summation I think this is something that should be implemented,
    I don't see any arguments against implementing this atleast for arrays
    and classes, like we already have for function parameters.
    I think we had plenty of arguments against it last time it was
    discussed. You could see it here for example:
    http://marc.info/?l=php-internals&m=118478789527042&w=2
    But I can repeat.

    Return types are useful in statically compiled languages, since they
    enable static type control. Since PHP has no static type control, return
    type is useless for the function client - the fact that function returns
    type X itself can be found in the documentation (where it belongs) -
    that includes PHPDoc for the smarter IDEs out there - but code-wise
    there's no useful action I can take using this information that I can't
    take using just what function actually returns and be safer.

    Return type definition can prohibit function from returning different
    types, however here we have two problems. First is that function
    definition and code is usually written by the same person in the same
    (very small) context, and this person has to be somewhat absent-minded
    to forget what function returns from definition to return a dozen lines
    below. Supporting such absent-mindedness with language constructs
    doesn't appear appropriate. Second is that only action return type
    definition could take in this case is break the application in runtime,
    which would be of little help to our absent-minded function writer and
    especially to its client.

    But even worse, since on the client side you have no way to enforce this
    restriction, you can't even rely on it in any context - what if the
    absent-minded function writer forgot to put the type restriction? If the
    type was important for you, you'd have to check it anyway, since you
    have no way to enforce the restriction on the client side! Since your
    enforcement on one side and your usage of the data is on the other, the
    enforcement is unreliable and thus useless.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Jessie Hernandez at Apr 30, 2008 at 2:14 am

    Sam Barrow wrote:
    Well in summation I think this is something that should be implemented,
    I don't see any arguments against implementing this atleast for arrays
    and classes, like we already have for function parameters.

    The only thing left would be to decide on the syntax

    public array function x() { // Probably the easiest
    public array x() { // I like this best, if it's possible
    public function x() return array { // Probably not, just throwing it out
    there

    Agree?
    How about using the ActionScript syntax?

    public function x():array { ... }


    --

    Jessie Hernandez
    Zend Certified Engineer (http://zend.com/zce.php?c=ZEND006359&r=222727282)
  • Arvids Godjuks at Apr 30, 2008 at 6:23 am
    I'm +1 for this syntax

    function int myfunction(int $param)
    {
    return $someint;
    }

    C/C++ like, easy to understand


    And bad idea about making a return type "function" - looks very useless and
    will not be used a lot. Work with objects with methods returning an object
    of some kind, then you can do

    $object->method()->method2()->method3();

    P.S. I think this thread should be merged with function param type hinting
    because they come together and should be implemented together,
  • Alain Williams at Apr 30, 2008 at 7:27 am

    On Wed, Apr 30, 2008 at 09:23:17AM +0300, Arvids Godjuks wrote:
    I'm +1 for this syntax

    function int myfunction(int $param)
    {
    return $someint;
    }

    C/C++ like, easy to understand
    +1 -- least confusion to most people.

    Taking it a bit further, if the function returns a reference (eg to its argument):

    function int &myfunction(int &$param)

    Alternative could be:
    function &int myfunction(int &$param)

    But I think that the first form is better.
    And bad idea about making a return type "function" - looks very useless and
    will not be used a lot. Work with objects with methods returning an object
    of some kind, then you can do

    $object->method()->method2()->method3();

    P.S. I think this thread should be merged with function param type hinting
    because they come together and should be implemented together,
    Sam has done much work on param type hinting, we should thank him for his hard work.

    --
    Alain Williams
    Linux 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
    Chairman of UKUUG: http://www.ukuug.org/
    #include <std_disclaimer.h>
  • Sam Barrow at Apr 30, 2008 at 11:54 am

    On Wed, 2008-04-30 at 08:27 +0100, Alain Williams wrote:
    On Wed, Apr 30, 2008 at 09:23:17AM +0300, Arvids Godjuks wrote:
    I'm +1 for this syntax

    function int myfunction(int $param)
    {
    return $someint;
    }

    C/C++ like, easy to understand
    +1 -- least confusion to most people.

    Taking it a bit further, if the function returns a reference (eg to its argument):

    function int &myfunction(int &$param)

    Alternative could be:
    function &int myfunction(int &$param)
    I like this better, I think this would just be a matter of ordering
    arguments in the parser.
    But I think that the first form is better.
    And bad idea about making a return type "function" - looks very useless and
    will not be used a lot. Work with objects with methods returning an object
    of some kind, then you can do

    $object->method()->method2()->method3();

    P.S. I think this thread should be merged with function param type hinting
    because they come together and should be implemented together,
    Sam has done much work on param type hinting, we should thank him for his hard work.

    --
    Alain Williams
    Linux 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
    Chairman of UKUUG: http://www.ukuug.org/
    #include <std_disclaimer.h>
  • Keryx Web at Apr 30, 2008 at 8:42 pm

    Alain Williams skrev:
    Taking it a bit further, if the function returns a reference (eg to its argument):

    function int &myfunction(int &$param)

    Alternative could be:
    function &int myfunction(int &$param)

    But I think that the first form is better.
    From one whose job it is to daily *teach* PHP. The first form is very
    much better.

    And:

    Suggestions to omit the word "function" altogether will be a nightmare
    from a teaching point of view. Convenience for experienced programmers
    should not come at the cost of unnecessary heightening of the threshold
    for newcomers.

    And:

    Once again, the main language besides PHP for most web developers is
    JavaScript. Actionscript has been mentioned. The future of Actionscript
    is ES 4. And from what I've recently read JavaScript is now the most
    language used of all. Anyway, here's from Brendan E:

    function f(a : int, b : String, c : Object) : RetType
    {
    // arguments are guaranteed to match types
    // return value must convert to or match RetType
    }

    Personally I believe that the colon adds readability. *If* return type
    hints are accepted I think this syntax is the best. (I do *not* think
    PHP should add anything else from ES 4 when it comes to types.)


    Lars Gunther
  • Alain Williams at Apr 30, 2008 at 8:55 pm

    On Wed, Apr 30, 2008 at 10:42:04PM +0200, Keryx Web wrote:
    Alain Williams skrev:
    Taking it a bit further, if the function returns a reference (eg to its
    argument):

    function int &myfunction(int &$param)

    Alternative could be:
    function &int myfunction(int &$param)

    But I think that the first form is better.
    From one whose job it is to daily *teach* PHP. The first form is very
    much better.

    And:

    Suggestions to omit the word "function" altogether will be a nightmare
    from a teaching point of view. Convenience for experienced programmers
    should not come at the cost of unnecessary heightening of the threshold
    for newcomers.
    +1. We also don't want to break existing code or have two ways of doing
    the same thing (that is perl's job :-) )
    And:

    Once again, the main language besides PHP for most web developers is
    JavaScript. Actionscript has been mentioned. The future of Actionscript
    is ES 4. And from what I've recently read JavaScript is now the most
    language used of all. Anyway, here's from Brendan E:

    function f(a : int, b : String, c : Object) : RetType
    {
    // arguments are guaranteed to match types
    // return value must convert to or match RetType
    }
    Nice in some ways, except that it is different from the way that type hinting
    works in PHP5 classes - again: keep to one way of doing things.

    ': RetType' might be possible, but it is very different from where type hints
    are given currently in PHP.

    Stick with:

    function int &myfunction(int &$param)
    Personally I believe that the colon adds readability. *If* return type
    hints are accepted I think this syntax is the best. (I do *not* think
    PHP should add anything else from ES 4 when it comes to types.)
    --
    Alain Williams
    Linux 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
    Chairman of UKUUG: http://www.ukuug.org/
    #include <std_disclaimer.h>
  • Keryx Web at May 1, 2008 at 9:46 am

    Alain Williams skrev:

    Nice in some ways, except that it is different from the way that type hinting
    works in PHP5 classes - again: keep to one way of doing things.

    ': RetType' might be possible, but it is very different from where type hints
    are given currently in PHP.

    Stick with:

    function int &myfunction(int &$param)
    Yes, on second thought I agree. "Keep to one way of doing things" is
    definitely sound advice from a teaching POV.


    Lars Gunther
  • Sam Barrow at Apr 30, 2008 at 11:53 am

    On Wed, 2008-04-30 at 09:23 +0300, Arvids Godjuks wrote:
    I'm +1 for this syntax

    function int myfunction(int $param)
    {
    return $someint;
    }

    C/C++ like, easy to understand


    And bad idea about making a return type "function" - looks very
    useless and will not be used a lot. Work with objects with methods
    returning an object of some kind, then you can do
    Function is a reserved keyword in PHP anyway, it would cause problems in
    numerous places if it was used as a type.
    $object->method()->method2()->method3();

    P.S. I think this thread should be merged with function param type
    hinting because they come together and should be implemented together,
    Well this is two parts, class/array hinting and scalar hinting. Class
    and array hinting is already implemented, so for now I'm just pushing
    for that in return types.
  • Sam Barrow at Apr 30, 2008 at 11:51 am
    On Tue, 2008-04-29 at 22:13 -0400, Jessie Hernandez wrote:
    Sam Barrow wrote:
    Well in summation I think this is something that should be implemented,
    I don't see any arguments against implementing this atleast for arrays
    and classes, like we already have for function parameters.

    The only thing left would be to decide on the syntax

    public array function x() { // Probably the easiest
    public array x() { // I like this best, if it's possible
    public function x() return array { // Probably not, just throwing it out
    there

    Agree?
    How about using the ActionScript syntax?

    public function x():array { ... }
    I like that, but in that case we might as well leave out the colon.
    --

    Jessie Hernandez
    Zend Certified Engineer (http://zend.com/zce.php?c=ZEND006359&r=222727282)
  • Michal Dziemianko at Apr 25, 2008 at 9:23 pm
    Hello everybody,
    I am new here (just reading for last couple of days), so firstly nice
    to meet you:)
    This discussion seems quite interesting for me and it would be nice
    if I can join...

    Sam Barrow napisal:
    im not sure the following has been explicitly proposed, but how about
    omitting the 'return' keyword and placing the return type hint before
    the function identifier

    function int a($b, $c) {}
    This is, but I don't think this is possible, due to confusion with the
    keywords (public, private, static, abstract, etc).
    Parser should be able to handle it if the grammar is correct.
    "something something2 somethign3 int foo(...)" works fine in some
    languages.

    LALR parser (Bison is used, isn't it?) is probably the most powerful
    parser practically used, and certainly can handle such a set of
    keywords correctly - even without "function" keyword (that makes
    parsing way easier) - or maybe I have missed some piece of syntax
    that might cause the problem (then my apologies)

    As there is a person working on converting parser to Lemon, maybe it
    would be wise to talk with him (her?), so the grammar is cleaned to
    handle it.
    Plus this leads to
    long strings of keywords.
    imho it is shorter - one keyword less. Actually it is also less
    confusing for me - maybe because I am using C/C++ and Java a lot
    where the syntax is equivalent. And if syntax is strict - i.e.
    modifiers first, then returned type - is quite well-readable - name
    of the function in the end, returned type just before.

    The version with "returns" seems to me like "throws" phrase from e.g.
    Java. Btw there was already such a solution in Pascal, but instead of
    "returns" colon was used:

    function foo(...):integer begin
    ...
    end

    Cheers,
    Michal Dziemianko

    PS. The idea is great anyways - I was always thinking why it is not
    implemented:))
  • Edward Z. Yang at Apr 25, 2008 at 10:47 pm

    Sam Barrow wrote:
    Attached is my return type hinting patch. [snip]
    I have a question independent of syntax/design-concerns: does this patch
    utilize typed returns to afford performance benefits to userland code
    that use it?

    --
    Edward Z. Yang GnuPG: 0x869C48DA
    HTML Purifier <http://htmlpurifier.org> Anti-XSS Filter
    [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]

Related Discussions

People

Translate

site design / logo © 2022 Grokbase