FAQ
Hello ladies and gentlemen,

I made a patch that implements an experimental return type hint,
therefore we need discuss much about this yet, right? :)

My idea uses (php-type) and +className as notation, see below.

- PHP types

function (string) foo(...) { } // Unicode string too
function (object) foo(...) { } // Strict
function (array) foo(...) { } // Strict
function (bool) foo(...) { } // Strict
function (int) foo(...) { } // Accepts numeric string
function (double) foo(...) { } // Accepts numeric string


:: Question ---------------------------
- Add (resource), (unicode), (void) ? |
---------------------------------------

- Userland types (like actual parameter type-hint)

function +className foo(...) { }
function +interfaceName foo(...) { }
// Uses the class/interface 'int', not the type
function +int foo(...) { }

:: Question ----------------------------
- Weird syntax? |
----------------------------------------

:: Examples ------------------------------------------------

interface Itest { }
class bar implements Itest { }
class foo extends bar { }

class test {
static public function +Itest testing($instance) {
return $instance;
}
}

test::testing(new bar);
test::testing(new foo);
test::testing(new stdclass); // Error!
// Catchable fatal error: The returned value must implement interface
Itest

-----------------------------------------

class foo {
public function +self getInstance() {
return $this;
}
}

$test = new foo;
var_dump($test->getInstance()); // OK!

object(foo)#1 (0) {
}


Finally, it's nice or poor syntax?

What must be improved/changed? (All?)


Patch: http://felipe.ath.cx/diff/return_type_hint.diff
Tests: http://felipe.ath.cx/diff/tests/

--
Regards,
Felipe Pena.

Search Discussions

  • Cristian Rodríguez at Apr 7, 2008 at 4:11 am

    Felipe Pena escribió:
    Hello ladies and gentlemen,

    I made a patch that implements an experimental return type hint,
    therefore we need discuss much about this yet, right? :)
    Thanks for raising this issue !!

    function (int) foo(...) { } // Accepts numeric string
    function (double) foo(...) { } // Accepts numeric string
    hrmmm.. nope. neither double nor int should accept numeric string..


    :: Question ---------------------------
    - Add (resource), (unicode), (void) ? |
    ---------------------------------------
    yes !!

    :: Question ----------------------------
    - Weird syntax? |
    ----------------------------------------
    Yes, not intuitive at all...

    What must be improved/changed? (All?)
    Dunno, Have not tested the patch yet, but will :)

    Thanks.

    --
    “If debugging is the process of removing bugs, then programming must be
    the process of putting them in.” – Edsger Dijkstra

    Cristian Rodríguez R.
    Platform/OpenSUSE - Core Services
    SUSE LINUX Products GmbH
    Research & Development
    http://www.opensuse.org/
  • Mike Lively at Apr 7, 2008 at 4:57 am

    On Sun, Apr 6, 2008 at 8:41 PM, Felipe Pena wrote:

    - PHP types

    function (string) foo(...) { } // Unicode string too
    function (object) foo(...) { } // Strict
    function (array) foo(...) { } // Strict
    function (bool) foo(...) { } // Strict
    function (int) foo(...) { } // Accepts numeric string
    function (double) foo(...) { } // Accepts numeric string

    If there ever were return type hinting in PHP I don't think it would be wise
    to support PHP Types unless parameter hints were changed to support them.
    It's just inconsistent.

    :: Question ----------------------------
    - Weird syntax? |
    ----------------------------------------
    Yes, is there any reason why any special characters are needed?
  • Derick Rethans at Apr 7, 2008 at 1:44 pm

    On Sun, 6 Apr 2008, Mike Lively wrote:
    On Sun, Apr 6, 2008 at 8:41 PM, Felipe Pena wrote:

    - PHP types

    function (string) foo(...) { } // Unicode string too
    function (object) foo(...) { } // Strict
    function (array) foo(...) { } // Strict
    function (bool) foo(...) { } // Strict
    function (int) foo(...) { } // Accepts numeric string
    function (double) foo(...) { } // Accepts numeric string

    If there ever were return type hinting in PHP I don't think it would be wise
    to support PHP Types unless parameter hints were changed to support them.
    It's just inconsistent.
    Right, this shouldn't even be on the agenda before we have scalar type
    hints. So, perhaps you can make a patch for that first Felipe?

    regards,
    Derick
  • Felipe Pena at Apr 7, 2008 at 1:58 pm

    Em Seg, 2008-04-07 às 15:44 +0200, Derick Rethans escreveu:
    On Sun, 6 Apr 2008, Mike Lively wrote:
    On Sun, Apr 6, 2008 at 8:41 PM, Felipe Pena wrote:

    - PHP types

    function (string) foo(...) { } // Unicode string too
    function (object) foo(...) { } // Strict
    function (array) foo(...) { } // Strict
    function (bool) foo(...) { } // Strict
    function (int) foo(...) { } // Accepts numeric string
    function (double) foo(...) { } // Accepts numeric string

    If there ever were return type hinting in PHP I don't think it would be wise
    to support PHP Types unless parameter hints were changed to support them.
    It's just inconsistent.
    Right, this shouldn't even be on the agenda before we have scalar type
    hints. So, perhaps you can make a patch for that first Felipe?
    I don't thought this before!
    Sure, i'll try provide a patch.

    Thanks.

    --
    Regards,
    Felipe Pena.
  • Sam Barrow at Apr 7, 2008 at 2:02 pm
    I have a scalar type hinting patch on my blog at www.sambarrow.com

    On Mon, 2008-04-07 at 10:57 -0300, Felipe Pena wrote:

    I don't thought this before!
    Sure, i'll try provide a patch.
  • Christian Schneider at Apr 7, 2008 at 4:49 pm

    Felipe Pena wrote:
    Right, this shouldn't even be on the agenda before we have scalar type
    hints. So, perhaps you can make a patch for that first Felipe?
    I don't thought this before!
    Sure, i'll try provide a patch.
    Just so this side was mentioned once again too: There are people who
    consider type hints and especially scalar type hints A Bad Thing(tm) as
    it is contrary to the PHP strength of dynamic typing and automatic type
    conversion.

    I just ran into this (IMHO unnecessary) limitation with array_reduce:
    Why should it only reduce to an int? Why not a string or an array? I
    plan on submitting a patch for PHP 6 to allow other types too.

    - Chris
  • Stanislav Malyshev at Apr 7, 2008 at 4:58 pm
    Hi!
    I just ran into this (IMHO unnecessary) limitation with array_reduce:
    Why should it only reduce to an int? Why not a string or an array? I
    plan on submitting a patch for PHP 6 to allow other types too.
    I'm not sure I understand - how array_reduce is related to having type
    hints? You could make array_reduce to do additional things, but that
    doesn't require introducing strong typing into php.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Christian Schneider at Apr 7, 2008 at 5:12 pm

    Stanislav Malyshev wrote:
    I'm not sure I understand - how array_reduce is related to having type
    hints? You could make array_reduce to do additional things, but that
    doesn't require introducing strong typing into php.
    The relation between array_reduce and scalar type hints is that API
    start to enforce certain types where they should not just because the
    programmer thinks it is a good idea.

    Currently the third parameter $initial of array_reduce only allows int.
    So instead of allowing any zval and leaving it to the callback function
    to deal with it a specific type is enforced. You can work around this by
    checking for NULL inside the callback and initializing it there but that
    does not work either if you use a built-in function as callback.

    - Chris
  • Lukas Kahwe Smith at Apr 7, 2008 at 5:40 pm

    On 07.04.2008, at 18:57, Stanislav Malyshev wrote:
    Hi!
    I just ran into this (IMHO unnecessary) limitation with array_reduce:
    Why should it only reduce to an int? Why not a string or an array? I
    plan on submitting a patch for PHP 6 to allow other types too.
    I'm not sure I understand - how array_reduce is related to having
    type hints? You could make array_reduce to do additional things, but
    that doesn't require introducing strong typing into php.
    PHP should be as flexible about types as possible. I never used
    array_reduce() so I do not know its history. But some of you might
    remember the change in behavior from array_merge() which was the
    result of a switch to a more strict parameter parsing API, which now
    returns false when you pass in NULL. A fair amount of people believe
    that this is the wrong direction to take. Continuously expanding type
    hints relates to this concern.

    regards,
    Lukas
  • Lukas Kahwe Smith at Apr 7, 2008 at 5:37 pm

    On 07.04.2008, at 18:49, Christian Schneider wrote:
    Felipe Pena wrote:
    Right, this shouldn't even be on the agenda before we have scalar
    type
    hints. So, perhaps you can make a patch for that first Felipe?
    I don't thought this before!
    Sure, i'll try provide a patch.
    Just so this side was mentioned once again too: There are people who
    consider type hints and especially scalar type hints A Bad Thing(tm)
    as
    it is contrary to the PHP strength of dynamic typing and automatic
    type
    conversion.
    Right if at all I would agree on having a type hint "scalar", but not
    a separate one per type.

    regards,
    Lukas
  • Stanislav Malyshev at Apr 7, 2008 at 5:59 pm
    Hi!
    Right if at all I would agree on having a type hint "scalar", but not a
    separate one per type.
    IMO (as already was discussed like 10 times?) "scalar" makes no sense.
    It doesn't save you any checks, and doesn't provide any useful
    information and can't perform any useful conversions, etc. for you. BTW,
    the statement to usefulness of "scalar" is that no C API function ever
    needed "scalar" as parameter type - and while we had a lot of formats
    for zend_parse_parameters, including objects, arrays, resources,
    numbers, strings of various kinds, callbacks, etc., we don't have
    "scalar" one. I consider it a strong indication that this idea is not as
    good as it might seem.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Lukas Kahwe Smith at Apr 13, 2008 at 10:07 am

    On 07.04.2008, at 19:59, Stanislav Malyshev wrote:
    Hi!
    Right if at all I would agree on having a type hint "scalar", but
    not a separate one per type.
    IMO (as already was discussed like 10 times?) "scalar" makes no
    sense. It doesn't save you any checks, and doesn't provide any
    useful information and can't perform any useful conversions, etc.
    for you. BTW, the statement to usefulness of "scalar" is that no C
    API function ever needed "scalar" as parameter type - and while we
    had a lot of formats for zend_parse_parameters, including objects,
    arrays, resources, numbers, strings of various kinds, callbacks,
    etc., we don't have "scalar" one. I consider it a strong indication
    that this idea is not as good as it might seem.
    Maybe we should be thinking more in terms of "scalar" sometimes, then
    we might not have gotten that BC break in array_merge().

    regards,
    Lukas
  • Chris Stockton at Apr 14, 2008 at 3:06 am
    Why on earth would you have int, string, resource, etc "return type hints"
    and then turn around and suggest for parameter hinting just add a scalar
    type? That makes no sense and is so inconsistent.

    static int function retarded(scalar $value) {
    return (int) $value; // lol....
    }
  • Christian Schneider at Apr 14, 2008 at 2:28 pm

    Chris Stockton schrieb:
    Why on earth would you have int, string, resource, etc "return type hints"
    and then turn around and suggest for parameter hinting just add a scalar
    type? That makes no sense and is so inconsistent.

    static int function retarded(scalar $value) {
    return (int) $value; // lol....
    }
    Let me turn your question around: Why on earth would someone restrict a
    function to int when string works just as well?

    function int foo_flexible(scalar $x) { return $x + 42; }
    $foo = foo_flexible($value);

    function int foo_retarded(int $x) { return $x + 42; }
    $foo = foo_retarded((int)$value); # :-(

    That said, I'll be using
    function foo($x) { return $x + 42; }
    anyway and let PHP warnings take care of the rest ;-)

    - Chris
  • Stanislav Malyshev at Apr 14, 2008 at 4:56 pm
    Hi!
    Let me turn your question around: Why on earth would someone restrict a
    function to int when string works just as well?

    function int foo_flexible(scalar $x) { return $x + 42; }
    $foo = foo_flexible($value);
    Now let's think - what happens if $x is *not* scalar? So the real code
    would be like this:

    function foo_flexible(scalar $x) { return $x + 42; }
    if(!is_scalar($value)) {
    $foo = foo_flexible($value);
    } else {
    // ok, what do I do now?
    }

    And so for each instance. Ugly.
    That said, I'll be using
    function foo($x) { return $x + 42; }
    anyway and let PHP warnings take care of the rest ;-)
    Amen to that.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Chris Stockton at Apr 14, 2008 at 5:04 pm
    You are missing the point, why be strict on return types, and liberal on
    parameters? Be strict consistently or be liberal consistently. Or, keep php,
    php. I could care less as long as things are consistent, although I think
    only supporting scalar is silly regardless of type juggling.

    -Chris
    On Mon, Apr 14, 2008 at 7:28 AM, Christian Schneider wrote:

    Chris Stockton schrieb:

    Why on earth would you have int, string, resource, etc "return type
    hints"
    and then turn around and suggest for parameter hinting just add a scalar
    type? That makes no sense and is so inconsistent.

    static int function retarded(scalar $value) {
    return (int) $value; // lol....
    }
    Let me turn your question around: Why on earth would someone restrict a
    function to int when string works just as well?

    function int foo_flexible(scalar $x) { return $x + 42; }
    $foo = foo_flexible($value);

    function int foo_retarded(int $x) { return $x + 42; }
    $foo = foo_retarded((int)$value); # :-(

    That said, I'll be using
    function foo($x) { return $x + 42; }
    anyway and let PHP warnings take care of the rest ;-)

    - Chris
  • Christian Schneider at Apr 14, 2008 at 5:49 pm

    Am 14.04.2008 um 19:04 schrieb Chris Stockton:
    You are missing the point, why be strict on return types, and
    liberal on parameters? Be strict
    Because IMHO a function can easily specify what it is returning but
    should be flexible in what it accepts - that's what a good PHP API is
    to me.
    Asking for consistency just for the sake of consistency seems wrong
    here. Especially when it sends out the message that function
    parameters should be (over-)specified to exact types.
    consistently or be liberal consistently. Or, keep php, php. I could
    care less as long as things are
    Keeping PHP close to the original principles of KISS and "make common
    things easy" is also a goal of mine.

    - Chris
  • Lukas Kahwe Smith at Apr 14, 2008 at 9:22 pm

    On 14.04.2008, at 19:49, Christian Schneider wrote:
    Am 14.04.2008 um 19:04 schrieb Chris Stockton:
    You are missing the point, why be strict on return types, and
    liberal on parameters? Be strict
    Because IMHO a function can easily specify what it is returning but
    should be flexible in what it accepts - that's what a good PHP API
    is to me.
    Asking for consistency just for the sake of consistency seems wrong
    here. Especially when it sends out the message that function
    parameters should be (over-)specified to exact types.
    Right .. this is so beautiful. So we get type hints for parameters,
    then someone starts implements a patch for return types (for
    consistency) and goes a bit further than what we already have and
    suddenly (for consistency) the parameter type hints need to be
    adjusted as well. Err .. what? Who is missing the point here? I think
    this illustrates the consistency arguments that are thrown around
    since recently quite well.

    Either it makes sense or does not make sense in its own right. Do not
    use consistency as an excuse to add things. Now we have had this
    debate, but I guess it ends up being a fairly non technical debate
    about who likes what and who wants PHP to change in what ways .. oh
    well .. I give up .. this debate is a horse that is so dead it can
    never die anyways.

    regards,
    Lukas
  • Sam Barrow at Apr 15, 2008 at 5:05 am
    If somebody does have a patch for this or is working on one let me know. Whether this will be implemented or not I would like to assist with this patch so I can use it for personal use at the very least.
  • Arvids Godjuks at Apr 15, 2008 at 8:27 am
    Thouse who are asking about type hinting for function args are right. It is
    logical to implement return type hinting with arg type hinting.
    They should work either independantly (you can specify any on them or all
    together) or if you declare return type - declare arg types too (then we
    should have 'mixed' type too, some functions can return array or false on
    error, ect).

    Why we need type hinting?
    Here is an example


    array function myQuery(int $id){
    $result = mysql_query('SELECT * FROM table WHERE id = '.$id);
    // Make a array from result
    return $array;
    }
    $id = '192b46';
    $data = myQuery($id);

    If some checks are implemented about what is passed, then this will be an
    error (or exception witch can be cathed). And type conversion to int isn't
    good, because you will get 192 instead if 19246. It's like array and object
    type hinting now implemented. And i can be sure I will get an array as a
    result.
    Maybe it is good idea to make type conversions on function args, then we
    don't need to make "id = '.(int)$id" ourselfs.
  • Arvids Godjuks at Apr 15, 2008 at 11:28 am
    Christian Schneider

    We have 2 possibilities.
    * Throw an error
    * Make type conversion

    What to select is PHP developers team prerogative.

    About example - that's MySQL who is very tollerant, other databases may not
    threat well things like passing an ID to numeric field as string. That's bad
    style to me. If you have a numeric filed - pass numeric values. If you have
    character field - please pass strings. That's more like coding style and
    isn't related to this disscussion. And if you have a type-hinted language,
    then your ID will be integer anyway or your programm will segfault if you
    try to assing a string to int type variable.

    We are not talking about MySQL's capability to convert types itself and type
    hinting isn't related only to databases - i just took first example I could
    think of.

    About conversions - see how PHP converts types - that's written in the
    manual
    echo (int)42; -> 42
    echo (int)"42foo"; -> 42
    echo (int)"foo"; -> 0
    echo (int)"foo42"; -> 0

    At least on bad ID's like "foo" or "foo42" you will have 0 and usualy there
    are no ids with value 0 in databases, so you will get "No data avaliable" -
    that's my approach witch proved to be good one over the years.
  • Felipe Pena at Apr 15, 2008 at 11:40 am

    Em Ter, 2008-04-15 às 01:05 -0400, Sam Barrow escreveu:
    If somebody does have a patch for this or is working on one let me know. Whether this will be implemented or not I would like to assist with this patch so I can use it for personal use at the very least.
    I already made two separated patches for param. and return value type
    hints. I'll create a new thread and start discussion ASAP.

    --
    Regards,
    Felipe Pena.
  • Stanislav Malyshev at Apr 15, 2008 at 6:14 pm

    I already made two separated patches for param. and return value type
    hints. I'll create a new thread and start discussion ASAP.
    Why not put it to the wiki?
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Arvids Godjuks at Apr 16, 2008 at 6:49 am
    2008/4/15, Felipe Pena <felipensp@gmail.com>:
    Em Ter, 2008-04-15 às 01:05 -0400, Sam Barrow escreveu:

    If somebody does have a patch for this or is working on one let me know.
    Whether this will be implemented or not I would like to assist with this
    patch so I can use it for personal use at the very least.


    I already made two separated patches for param. and return value type
    hints. I'll create a new thread and start discussion ASAP.

    --
    Regards,

    Felipe Pena.

    That's a simple function given. What if you need to use id many times. Then
    your function will start with $id = (int)$id; or settype('int', $id);
  • Richard Quadling at Apr 7, 2008 at 8:46 pm

    On 07/04/2008, Christian Schneider wrote:
    Just so this side was mentioned once again too: There are people who
    consider type hints and especially scalar type hints A Bad Thing(tm) as
    it is contrary to the PHP strength of dynamic typing and automatic type
    conversion.
    We are told that user data is dirty. Cleaning it is essential. One of
    the simplest ways is to cast the data to the right type. If they enter
    a date, then make sure it is a date by converting it to a date - if it
    can't convert then it wasn't a date. Why would you retain the string
    as your PRIMARY value? If you intend to do date manipulation you have
    to convert it. To use scalars they have to be in the right type. I
    cannot take 2 days from a string which is a date without having to do
    some conversion.

    The net result is that most user data should end up in the correct type anyway.

    So at what stage does this dynamic juggling of scalars take place?

    And why is it considered non-dynamic having a function declaration
    tell third party developers the scalar type of the parameters should
    be? If it was truly dynamic, they would be juggled for me rather than
    have me do it in userland.

    About the only time juggling is effective is in string concatenation.
    And even then it misses booleans! Do I get "true"/"false"? No I get
    nothing or 1. So I have to process it.

    Type juggling just doesn't seem to fit well with me.

    --
    -----
    Richard Quadling
    Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
    "Standing on the shoulders of some very clever giants!"
  • Christian Schneider at Apr 7, 2008 at 9:40 pm

    Richard Quadling schrieb:
    Type juggling just doesn't seem to fit well with me.
    You seem to live in a completely different PHP world. Because in our
    case we use (yes, knowingly use) the PHP type juggling and it safes us
    lots of manual type conversions.

    We get input from all different sources as strings (_GET, MySQL, files)
    and in a lot of cases we just use it. We don't care if it's a string, a
    number or a float (or even null), if it yields the right result in our
    calculation it's fine.

    Now if a function only expects int (and truncates floats because of
    that) like array_reduce does with the $initial parameter then this
    function is crippled (for no good reason).

    Promoting type hints for PHP (and more so scalar type hints, especially
    specific scalar type hints like int) might give the impression to API
    developers that highly specified interfaces are better than more general
    ones. If we can learn something from the current hype around functional
    languages then it is the fact that generic, data type independant
    functions can be a very powerful tool. Something like array_* should be
    as generic as possible and API developers should also be aware of this
    topic and be given the right signals.

    Therefore my conclusion (abusing Einstein ;-)):
    Make interfaces as specific as *necessary* but *not more*.

    - Chris
  • Arvids Godjuks at Apr 8, 2008 at 9:02 am
    I think type hint's would be good optional functionality. Those who need
    will use it, others will not. I'd probably use it in some cases. Especially
    if named parameters are implemented.

    Sometimes what I really want is named parameter pass like

    function myfunc(array $array, string $string = null, int $someint = 0){
    }

    myfunc($myArray, someint = $mySomeInt);
  • Krister Karlström at Apr 8, 2008 at 9:17 am
    Hi!

    This is maybe getting a bit out of topic now, but what about
    function/method overloading using type hinting:

    function myfunc(string $data) { }
    function myfunc(int $data) { }
    function myfunc(myClass $data) { }

    This currently causes an error in PHP 5.2.5 that function myfunc() can't
    be redeclared. This would in my opinion be very useful for methods in
    classes.

    Greetings,
    Krister Karlström, Helsinki, Finland

    Arvids Godjuks wrote:
    I think type hint's would be good optional functionality. Those who need
    will use it, others will not. I'd probably use it in some cases. Especially
    if named parameters are implemented.

    Sometimes what I really want is named parameter pass like

    function myfunc(array $array, string $string = null, int $someint = 0){
    }

    myfunc($myArray, someint = $mySomeInt);
    --
    * Ing. Krister Karlström, Zend Certified Engineer *
    * Systemutvecklare, IT-Centralen *
    * Arcada - Nylands Svenska Yrkeshögskola *
    * Jan-Magnus Janssons plats 1, 00550 Helsingfors, Finland *
    * Tel: +358(20)7699699 GSM: +358(50)5328390 *
    * E-mail: krister.karlstrom@arcada.fi *
  • Arvids Godjuks at Apr 8, 2008 at 10:05 am
    Em, you have __call method in classes - via it you could implement ANY logic
    for overloading. It's written in manual here:
    http://www.php.net/manual/en/language.oop5.overloading.php

    KISS should be followed - no C++ style overloading is needed, PHP is a
    script language without strict type hinting.

    2008/4/8, Krister Karlström <krister.karlstrom@arcada.fi>:
    Hi!

    This is maybe getting a bit out of topic now, but what about
    function/method overloading using type hinting:

    function myfunc(string $data) { }
    function myfunc(int $data) { }
    function myfunc(myClass $data) { }

    This currently causes an error in PHP 5.2.5 that function myfunc() can't
    be redeclared. This would in my opinion be very useful for methods in
    classes.

    Greetings,
    Krister Karlström, Helsinki, Finland

    Arvids Godjuks wrote:

    I think type hint's would be good optional functionality. Those who need
    will use it, others will not. I'd probably use it in some cases.
    Especially
    if named parameters are implemented.

    Sometimes what I really want is named parameter pass like

    function myfunc(array $array, string $string = null, int $someint = 0){
    }

    myfunc($myArray, someint = $mySomeInt);
    --
    * Ing. Krister Karlström, Zend Certified Engineer *
    * Systemutvecklare, IT-Centralen *
    * Arcada - Nylands Svenska Yrkeshögskola *
    * Jan-Magnus Janssons plats 1, 00550 Helsingfors, Finland *
    * Tel: +358(20)7699699 GSM: +358(50)5328390 *
    * E-mail: krister.karlstrom@arcada.fi *

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Krister Karlström at Apr 8, 2008 at 10:13 am
    Yes indeed you can implement it using the __call method, but it would be
    more readable if the language structure itself would support it. I
    suggested this just because I think that this is the most common way of
    using overloading, thus this probably would make sense to lot of users
    out there.

    But it was only a suggestion among others.

    /Krister Karlström

    Arvids Godjuks wrote:
    Em, you have __call method in classes - via it you could implement ANY logic
    for overloading. It's written in manual here:
    http://www.php.net/manual/en/language.oop5.overloading.php

    KISS should be followed - no C++ style overloading is needed, PHP is a
    script language without strict type hinting.

    2008/4/8, Krister Karlström <krister.karlstrom@arcada.fi>:
    Hi!

    This is maybe getting a bit out of topic now, but what about
    function/method overloading using type hinting:

    function myfunc(string $data) { }
    function myfunc(int $data) { }
    function myfunc(myClass $data) { }

    This currently causes an error in PHP 5.2.5 that function myfunc() can't
    be redeclared. This would in my opinion be very useful for methods in
    classes.

    Greetings,
    Krister Karlström, Helsinki, Finland

    Arvids Godjuks wrote:

    I think type hint's would be good optional functionality. Those who need
    will use it, others will not. I'd probably use it in some cases.
    Especially
    if named parameters are implemented.

    Sometimes what I really want is named parameter pass like

    function myfunc(array $array, string $string = null, int $someint = 0){
    }

    myfunc($myArray, someint = $mySomeInt);
  • Lukas Kahwe Smith at Apr 13, 2008 at 10:07 am

    On 08.04.2008, at 12:13, Krister Karlström wrote:
    Yes indeed you can implement it using the __call method, but it
    would be more readable if the language structure itself would
    support it. I suggested this just because I think that this is the
    most common way of using overloading, thus this probably would make
    sense to lot of users out there.
    I think polymorphism is exactly the opposite from easier to read. For
    the bulk of functions I will never need it (even if I am a type hint
    lover) and so by default I now have to look for all variations of a
    single method instead of knowing its either that one or its in
    __call() (well there is also inheritance, but lets now make it any
    harder for this fairly rare case). This is all a solution to a problem
    we do not have (but are trying to get with type hints)/
    I think type hint's would be good optional functionality. Those
    who need
    will use it, others will not. I'd probably use it in some cases.
    Especially
    if named parameters are implemented.

    Sometimes what I really want is named parameter pass like

    function myfunc(array $array, string $string = null, int $someint
    = 0){
    }

    myfunc($myArray, someint = $mySomeInt);
    Named parameters I see as much more useful, though I generally think
    that there are ways to ensure that the number of parameters stays
    small enough to not make named parameters necessary.

    regards,
    Lukas
  • Christian Schneider at Apr 8, 2008 at 10:54 am
    Actually nothing could support my point about giving the wrong signals
    better than these two postings: They are IMHO on the wrong track on how
    to make an interface better.

    Krister Karlström wrote:
    This is maybe getting a bit out of topic now, but what about
    function/method overloading using type hinting:

    function myfunc(string $data) { }
    function myfunc(int $data) { }
    function myfunc(myClass $data) { }
    <sarcasm>
    Go back to Java please ;-)
    </sarcasm>
    Arvids Godjuks wrote:
    I think type hint's would be good optional functionality. Those who need
    will use it, others will not. I'd probably use it in some cases.
    Especially if named parameters are implemented.

    Sometimes what I really want is named parameter pass like

    function myfunc(array $array, string $string = null, int $someint = 0){
    }

    myfunc($myArray, someint = $mySomeInt);
    While I think named parameters are a good idea I pointed out in older
    postings that I think this is a very crippled approach to it: You still
    have to define all the parameters you are going to accept. The real
    power and flexibility comes in if you accept (and handle) arbitrary
    argument lists.
    <plug>
    See http://itools.search.ch/ for an example of what I mean.
    </plug>

    Okay, enough evangelism for today, back to work :-)

    - Chris
  • Arvids Godjuks at Apr 8, 2008 at 10:12 am
    Yes it does, and not only for VB developers.
    I'm plain PHP developer (with some small Pascal and Delphi background) and I
    faced quite a lot situations when named parameters would give me a lot. In
    stead had to write some nasty code like

    myFunc($param1, $param2, array(), null, $paramX);
    myFunc($param1, array(), $param4, $param5, $paramX);

    And it wasn't a matter of placing function params in right order - I was
    just impossible. Actual alternatives were in writing functions wrappers or
    write specialized functions witch were doing the same taks, just didn't made
    checks for params.

    2008/4/8, Richard Quadling <rquadling@googlemail.com>:
    On 08/04/2008, Arvids Godjuks wrote:
    I think type hint's would be good optional functionality. Those who need
    will use it, others will not. I'd probably use it in some cases.
    Especially
    if named parameters are implemented.

    Sometimes what I really want is named parameter pass like

    function myfunc(array $array, string $string = null, int $someint = 0){
    }

    myfunc($myArray, someint = $mySomeInt);

    I think Named Parameters would be nice for VB developers.

    It makes a LOT of sense to have this I think.
  • Timothy Chandler at Apr 7, 2008 at 5:49 am
    I guess I should say it before anyone else does...

    "It's not the PHP way"

    - Timothy Chandler
    Simple Site Solutions

    Felipe Pena wrote:
    Hello ladies and gentlemen,

    I made a patch that implements an experimental return type hint,
    therefore we need discuss much about this yet, right? :)

    My idea uses (php-type) and +className as notation, see below.

    - PHP types

    function (string) foo(...) { } // Unicode string too
    function (object) foo(...) { } // Strict
    function (array) foo(...) { } // Strict
    function (bool) foo(...) { } // Strict
    function (int) foo(...) { } // Accepts numeric string
    function (double) foo(...) { } // Accepts numeric string


    :: Question ---------------------------
    - Add (resource), (unicode), (void) ? |
    ---------------------------------------

    - Userland types (like actual parameter type-hint)

    function +className foo(...) { }
    function +interfaceName foo(...) { }
    // Uses the class/interface 'int', not the type
    function +int foo(...) { }

    :: Question ----------------------------
    - Weird syntax? |
    ----------------------------------------

    :: Examples ------------------------------------------------

    interface Itest { }
    class bar implements Itest { }
    class foo extends bar { }

    class test {
    static public function +Itest testing($instance) {
    return $instance;
    }
    }

    test::testing(new bar);
    test::testing(new foo);
    test::testing(new stdclass); // Error!
    // Catchable fatal error: The returned value must implement interface
    Itest

    -----------------------------------------

    class foo {
    public function +self getInstance() {
    return $this;
    }
    }

    $test = new foo;
    var_dump($test->getInstance()); // OK!

    object(foo)#1 (0) {
    }


    Finally, it's nice or poor syntax?

    What must be improved/changed? (All?)


    Patch: http://felipe.ath.cx/diff/return_type_hint.diff
    Tests: http://felipe.ath.cx/diff/tests/
  • Richard Quadling at Apr 7, 2008 at 10:00 am

    On 07/04/2008, Timothy Chandler wrote:
    I guess I should say it before anyone else does...

    "It's not the PHP way"

    - Timothy Chandler
    Simple Site Solutions
    And before PHP6 neither was native Unicode.

    And before PHP5 neither was a lot of the cool features of OOP (yeah
    PHP4 had it but in a different way).

    The PHP way is, at best, how thing were done until enough people
    wanted it and it is now how things are done.




    --
    -----
    Richard Quadling
    Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
    "Standing on the shoulders of some very clever giants!"
  • Felipe Pena at Apr 7, 2008 at 11:07 am

    Em Seg, 2008-04-07 às 15:48 +1000, Timothy Chandler escreveu:
    I guess I should say it before anyone else does...

    "It's not the PHP way"
    Do you mean the way that i initially suggest?
    Anyway return type hints (probably)? will implemented,
    at least it was accepted in 'Minutes PHP Developers Meeting'.

    As far as i know, just wasn't decided the syntax.
    - Timothy Chandler
    Simple Site Solutions

    Felipe Pena wrote:
    Hello ladies and gentlemen,

    I made a patch that implements an experimental return type hint,
    therefore we need discuss much about this yet, right? :)

    My idea uses (php-type) and +className as notation, see below.

    - PHP types

    function (string) foo(...) { } // Unicode string too
    function (object) foo(...) { } // Strict
    function (array) foo(...) { } // Strict
    function (bool) foo(...) { } // Strict
    function (int) foo(...) { } // Accepts numeric string
    function (double) foo(...) { } // Accepts numeric string


    :: Question ---------------------------
    - Add (resource), (unicode), (void) ? |
    ---------------------------------------

    - Userland types (like actual parameter type-hint)

    function +className foo(...) { }
    function +interfaceName foo(...) { }
    // Uses the class/interface 'int', not the type
    function +int foo(...) { }

    :: Question ----------------------------
    - Weird syntax? |
    ----------------------------------------

    :: Examples ------------------------------------------------

    interface Itest { }
    class bar implements Itest { }
    class foo extends bar { }

    class test {
    static public function +Itest testing($instance) {
    return $instance;
    }
    }

    test::testing(new bar);
    test::testing(new foo);
    test::testing(new stdclass); // Error!
    // Catchable fatal error: The returned value must implement interface
    Itest

    -----------------------------------------

    class foo {
    public function +self getInstance() {
    return $this;
    }
    }

    $test = new foo;
    var_dump($test->getInstance()); // OK!

    object(foo)#1 (0) {
    }


    Finally, it's nice or poor syntax?

    What must be improved/changed? (All?)


    Patch: http://felipe.ath.cx/diff/return_type_hint.diff
    Tests: http://felipe.ath.cx/diff/tests/
    --
    Regards,
    Felipe Pena.
  • Felipe Pena at Apr 7, 2008 at 12:28 pm

    Em Seg, 2008-04-07 às 01:32 -0700, kalle@zesix.com escreveu:

    :: Question ----------------------------
    - Weird syntax? |
    ----------------------------------------
    The syntax with the type casting seems abit weird as I've wrote above, I
    would suggest perhaps making each datatype name a reserved keyword, eg.
    int, integer, bool, bolean ect.
    I really tried avoid this.
    This is the reason for two notations.

    --
    Regards,
    Felipe Pena.
  • Troels knak-nielsen at Apr 7, 2008 at 1:06 pm

    On Mon, Apr 7, 2008 at 2:28 PM, Felipe Pena wrote:
    class test {
    static public function +Itest testing($instance) {
    return $instance;
    }
    }
    A more sane syntax, might be something like:

    class test {
    static function testing($instance) : Itest {
    return $instance;
    }
    }

    --
    troels
  • Jarismar Chaves da Silva at Apr 7, 2008 at 1:14 pm
    Or something like this would be nice too, please avoid using +<TYPE> or
    (<TYPE>).

    class test {
    public static Itest function testing($instance) {
    return $instance;
    }
    }

    troels knak-nielsen wrote:
    On Mon, Apr 7, 2008 at 2:28 PM, Felipe Pena wrote:

    class test {
    static public function +Itest testing($instance) {
    return $instance;
    }
    }
    A more sane syntax, might be something like:

    class test {
    static function testing($instance) : Itest {
    return $instance;
    }
    }

    --
    troels
    --

    *Jarismar Chaves da Silva*
  • Felipe Pena at Apr 7, 2008 at 1:36 pm
    Hello,
    Em Seg, 2008-04-07 às 10:15 -0300, Jarismar Chaves da Silva escreveu:
    Or something like this would be nice too, please avoid using +<TYPE>
    or (<TYPE>).

    class test {
    public static Itest function testing($instance) {
    return $instance;
    }
    }

    troels knak-nielsen wrote:
    On Mon, Apr 7, 2008 at 2:28 PM, Felipe Pena wrote:

    class test {
    static public function +Itest testing($instance) {
    return $instance;
    }
    }
    A more sane syntax, might be something like:

    class test {
    static function testing($instance) : Itest {
    return $instance;
    }
    }

    --
    troels
    --
    Jarismar Chaves da Silva
    As i said previously:
    I really tried avoid this.
    This is the reason for two notations.
    Actually 'integer', 'double', 'string', etc are allowed in function, class and interface names.
    Using only 1 notation, we would have that make them keywords.

    --
    Regards,
    Felipe Pena.
  • Ben Ramsey at Apr 7, 2008 at 3:02 pm

    On 4/7/08 9:15 AM, Jarismar Chaves da Silva wrote:
    Or something like this would be nice too, please avoid using +<TYPE> or
    (<TYPE>).

    class test {
    public static Itest function testing($instance) {
    return $instance;
    }
    }
    I think this is the most intuitive approach. However, this means that regular
    function declarations would be like:

    Itest function testing($instance) {
    return $instance;
    }

    Would this present a problem?

Related Discussions

People

Translate

site design / logo © 2022 Grokbase