FAQ
Hello again!

Now with both parameter and return value type hints.

For parameter type hints, i have completed the actual implementation
with the leftover php types:
- string (binary string and unicode)
- integer (accepting numeric string too)
- double (accepting numeric string too)
- boolean ('0', '1', true, false)
- resource
- object

(Yes, following our dynamic typing)


Since then, the patch also includes new methods to Reflection:
- isInt()
- isDouble()
- isBool()
- isString()
- isObject()
- isResource()


And for return value, i have modified and improved the previous patch,
and now it is using only the "(type)" notation. Hence, that
implementation doesn't make any BC break.


Examples, patches and tests: http://wiki.php.net/rfc/typehint


Thanks.

--
Regards,
Felipe Pena.

Search Discussions

  • Arvids Godjuks at Apr 17, 2008 at 9:01 am
    What about types like
    array
    mixed

    Ok, for "mixed" we may not use type hinting at all - does patch allow to
    hint only part of function args?
    If we have a function, witch takes as 1st argument array or string and other
    args should have strict types or just use call like myFunc(Array($string),
    .....) ? This is just to know this for sure.

    2008/4/17, Felipe Pena <felipensp@gmail.com>:
    Hello again!

    Now with both parameter and return value type hints.

    For parameter type hints, i have completed the actual implementation
    with the leftover php types:
    - string (binary string and unicode)
    - integer (accepting numeric string too)
    - double (accepting numeric string too)
    - boolean ('0', '1', true, false)
    - resource
    - object

    (Yes, following our dynamic typing)


    Since then, the patch also includes new methods to Reflection:
    - isInt()
    - isDouble()
    - isBool()
    - isString()
    - isObject()
    - isResource()


    And for return value, i have modified and improved the previous patch,
    and now it is using only the "(type)" notation. Hence, that
    implementation doesn't make any BC break.


    Examples, patches and tests: http://wiki.php.net/rfc/typehint


    Thanks.

    --
    Regards,
    Felipe Pena.



    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Lucas van Dijk at Apr 17, 2008 at 9:34 am
    Array is already built in, and for mixed, as you already mentioned, indeed
    no type hinting. I definitely want this implemented, +1 from me.
    On Thu, Apr 17, 2008 at 11:01 AM, Arvids Godjuks wrote:

    What about types like
    array
    mixed

    Ok, for "mixed" we may not use type hinting at all - does patch allow to
    hint only part of function args?
    If we have a function, witch takes as 1st argument array or string and
    other
    args should have strict types or just use call like myFunc(Array($string),
    .....) ? This is just to know this for sure.

    2008/4/17, Felipe Pena <felipensp@gmail.com>:
    Hello again!

    Now with both parameter and return value type hints.

    For parameter type hints, i have completed the actual implementation
    with the leftover php types:
    - string (binary string and unicode)
    - integer (accepting numeric string too)
    - double (accepting numeric string too)
    - boolean ('0', '1', true, false)
    - resource
    - object

    (Yes, following our dynamic typing)


    Since then, the patch also includes new methods to Reflection:
    - isInt()
    - isDouble()
    - isBool()
    - isString()
    - isObject()
    - isResource()


    And for return value, i have modified and improved the previous patch,
    and now it is using only the "(type)" notation. Hence, that
    implementation doesn't make any BC break.


    Examples, patches and tests: http://wiki.php.net/rfc/typehint


    Thanks.

    --
    Regards,
    Felipe Pena.



    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Lucas
  • Christian Schneider at Apr 17, 2008 at 11:48 am

    Felipe Pena wrote:
    For parameter type hints, i have completed the actual implementation
    with the leftover php types:
    - string (binary string and unicode)
    - integer (accepting numeric string too)
    - double (accepting numeric string too)
    - boolean ('0', '1', true, false)
    - resource
    - object
    I don't like the difference between
    function (int) test($value) { ... }
    and
    function test(integer $value) { ... }

    I don't think we should introduce two different names for something
    which is basically the same. Even if there is (as I guess) a slight
    difference (int *really* being int and integer allowing strings
    containing numbers), which makes the WTF factor even higher IMHO.

    Also about "New tokens (new keywords)": I haven't tried the patch so
    excuse me asking. Does this mean $this->string is invalid because string
    is a new keyword? Then I'd be strongly against having these new keywords.

    Is there any performance impact for people not using type hints?

    Just to make it clear: I think type hinting is a Bad Idea(tm) anyway but
    *if* it is implemented I think you should consider the above points.

    - Chris
  • Arvids Godjuks at Apr 17, 2008 at 12:00 pm
    Christian Schneider


    I don't like the difference between
    function (int) test($value) { ... }
    and
    function test(integer $value) { ... }

    First is function return value should be int, second is function arg should
    be int.
    So full syntax will be like this

    function (integer) test(integer $value) { ... }

    That means function takes an integer as argument and returns integer value.
    If any is violated - Catchable error will be thrown.

    That's my understanding of this patch. Some more examples

    function (resource) query(string $table, array $where = array(), array
    $limit = array()) { ... }

    function (array) getData(string $table, array $limit = array(0, 20), array
    $where = array()) { /* cals query and generates an array from result */ }

    etc.
  • Christian Schneider at Apr 17, 2008 at 12:14 pm

    Arvids Godjuks wrote:
    So full syntax will be like this
    function (integer) test(integer $value) { ... }
    I guess you are right: int and integer seem to be aliase and both check
    for int *or* numeric strings, not the type int.
    It is also not clear if (string) accepts ints/floats which are often
    valid values.

    I think a table of which type hint accepts which values would be useful.

    And there also remains the issue with the keywords where I'd like to be
    enlightened :-)

    - Chris
  • Paul Biggar at Apr 17, 2008 at 12:52 pm
    Hi,

    Your current implementation seems to be inconsistent with both itself
    and the rest of PHP. I hope this can be rectified before it is
    included. PHP is inconsisent enough without adding more.


    1.) There are a number of is_* functions. It seems obvious that they
    should be consistent with this. So you're missing numeric and scalar.
    I'm not clear if there is a is_unicode(), but if so, that should be
    consistent too. (I believe scalar is particularly important, at a
    language level, since mixed and object are provided).

    2.) is_int has different semantics to the int type hint. Numeric
    strings qualify as the latter, but not the former. In general this is
    a problem. It seems type hints can only be made consistent if they
    convert the actual parameter to the type which is hinted. (Note that
    for call-by-reference, this will change the value in the caller, not
    just the copy in the callee - I think this is a good idea). As an
    example, this will fail, which it shouldnt: function y (int $x) {
    assert (is_int($x); } y ("24");

    3.) This doesnt seem to be integrated with class type hints, in the
    codebase. I wonder why that is? (I don't care all that much, I'm just
    wondering).

    I hope we can get these ironed out.

    Thanks in advance.
    Paul

    On Thu, Apr 17, 2008 at 5:50 AM, Felipe Pena wrote:
    Hello again!

    Now with both parameter and return value type hints.

    For parameter type hints, i have completed the actual implementation
    with the leftover php types:
    - string (binary string and unicode)
    - integer (accepting numeric string too)
    - double (accepting numeric string too)
    - boolean ('0', '1', true, false)
    - resource
    - object

    (Yes, following our dynamic typing)


    Since then, the patch also includes new methods to Reflection:
    - isInt()
    - isDouble()
    - isBool()
    - isString()
    - isObject()
    - isResource()


    And for return value, i have modified and improved the previous patch,
    and now it is using only the "(type)" notation. Hence, that
    implementation doesn't make any BC break.


    Examples, patches and tests: http://wiki.php.net/rfc/typehint


    Thanks.

    --
    Regards,
    Felipe Pena.


    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Paul Biggar
    paul.biggar@gmail.com
  • Sam Barrow at Apr 17, 2008 at 2:05 pm

    On Thu, 2008-04-17 at 14:52 +0200, Paul Biggar wrote:
    Hi,

    Your current implementation seems to be inconsistent with both itself
    and the rest of PHP. I hope this can be rectified before it is
    included. PHP is inconsisent enough without adding more.


    1.) There are a number of is_* functions. It seems obvious that they
    should be consistent with this. So you're missing numeric and scalar.
    I'm not clear if there is a is_unicode(), but if so, that should be
    consistent too. (I believe scalar is particularly important, at a
    language level, since mixed and object are provided).

    2.) is_int has different semantics to the int type hint. Numeric
    strings qualify as the latter, but not the former. In general this is
    a problem. It seems type hints can only be made consistent if they
    convert the actual parameter to the type which is hinted. (Note that
    for call-by-reference, this will change the value in the caller, not
    just the copy in the callee - I think this is a good idea). As an
    example, this will fail, which it shouldnt: function y (int $x) {
    assert (is_int($x); } y ("24");
    The problem with this is that there's not much point in converting the
    value. PHP will do that anyway, making this kind of pointless.
    3.) This doesnt seem to be integrated with class type hints, in the
    codebase. I wonder why that is? (I don't care all that much, I'm just
    wondering).
    This works in a different way. Rather than just checking the type, it
    checks the value (such as a numeric string).

    Overall, I think type hinting should work by checking the type. If it
    does not match, raise an error. For example, int means int, not numeric
    string.
    This only serves to include an additional type juggling system into php,
    which is very confusing.
  • Alain Williams at Apr 17, 2008 at 2:13 pm

    On Thu, Apr 17, 2008 at 10:01:13AM -0400, Sam Barrow wrote:
    On Thu, 2008-04-17 at 14:52 +0200, Paul Biggar wrote:

    just the copy in the callee - I think this is a good idea). As an
    example, this will fail, which it shouldnt: function y (int $x) {
    assert (is_int($x); } y ("24");
    The problem with this is that there's not much point in converting the
    value. PHP will do that anyway, making this kind of pointless.
    If inside y() you have something like:

    for( $i = 0; $i < $x; $i++ )

    you will end up converting $x to integer $x times ... which will eat
    CPU if $x is large -- I tried it.

    An:
    assert (is_int($x))
    followed by:
    $x = (int)$x
    is the way to go.
    This only serves to include an additional type juggling system into php,
    which is very confusing.
    If you don't understand it: don't use it.

    --
    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>
  • Paul Biggar at Apr 17, 2008 at 2:28 pm
    Hi Sam,

    On Thu, Apr 17, 2008 at 4:01 PM, Sam Barrow wrote:
    \> > 2.) is_int has different semantics to the int type hint. Numeric
    strings qualify as the latter, but not the former. In general this is
    a problem. It seems type hints can only be made consistent if they
    convert the actual parameter to the type which is hinted. (Note that
    for call-by-reference, this will change the value in the caller, not
    just the copy in the callee - I think this is a good idea). As an
    example, this will fail, which it shouldnt: function y (int $x) {
    assert (is_int($x); } y ("24");
    The problem with this is that there's not much point in converting the
    value. PHP will do that anyway, making this kind of pointless.
    That is not quite correct. PHP's weak typing is somewhat inconsistent,
    and in the example I included, it will not coerce the value of $x. An
    'int' type hint is not the same as is_int (), which is a mistake.

    It seems the easiest thing is to make the conversion mandatory at
    call-time. Alternatives would include weakening is_int(), or making
    the 'int' hint fail for numeric strings (as you mention below). I
    believe these two solutions are not as good.


    Overall, I think type hinting should work by checking the type. If it
    does not match, raise an error. For example, int means int, not numeric
    string.
    This only serves to include an additional type juggling system into php,
    which is very confusing.
    This is one alternative. The aim should be consistency (or as you say,
    avoiding confusion). This weak typing is already part of the language,
    so I don't believe it is inconsistent, though your suggestion clearly
    is. However, it is more consistent than, and therefore preferable to,
    the current patch.



    Thanks,
    Paul

    --
    Paul Biggar
    paul.biggar@gmail.com
  • Stanislav Malyshev at Apr 17, 2008 at 5:06 pm
    Hi!
    The problem with this is that there's not much point in converting the
    value. PHP will do that anyway, making this kind of pointless.
    There would be a point since PHP might convert to different type that
    you intended. Think of $foo = "My age is $age". If $age is supposed to
    be int, then converting int hint might help.
    Overall, I think type hinting should work by checking the type. If it
    does not match, raise an error. For example, int means int, not numeric
    string.
    What code scenario would make it necessary to distinguish between number
    stored as string and number stored as binary?
    This only serves to include an additional type juggling system into php,
    which is very confusing.
    There's already type juggling in PHP, and if you find it confusing, you
    find whole PHP and whole set of dynamic languages very confusing. I
    guess maybe C or Java would work better then :)
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Sam Barrow at Apr 17, 2008 at 5:16 pm

    On Thu, 2008-04-17 at 10:06 -0700, Stanislav Malyshev wrote:
    Hi!
    The problem with this is that there's not much point in converting the
    value. PHP will do that anyway, making this kind of pointless.
    There would be a point since PHP might convert to different type that
    you intended. Think of $foo = "My age is $age". If $age is supposed to
    be int, then converting int hint might help.
    Overall, I think type hinting should work by checking the type. If it
    does not match, raise an error. For example, int means int, not numeric
    string.
    What code scenario would make it necessary to distinguish between number
    stored as string and number stored as binary?
    This only serves to include an additional type juggling system into php,
    which is very confusing.
    There's already type juggling in PHP, and if you find it confusing, you
    find whole PHP and whole set of dynamic languages very confusing. I
    guess maybe C or Java would work better then :)
    I understand it very well, but why have a whole other system of type
    juggling? That would be duplicating type juggling functionality that's
    already in there.
  • Stanislav Malyshev at Apr 17, 2008 at 5:37 pm
    I understand it very well, but why have a whole other system of type
    It's the same system. The same system that makes internal functions work.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Stanislav Malyshev at Apr 17, 2008 at 5:03 pm
    Hi!
    Your current implementation seems to be inconsistent with both itself
    and the rest of PHP. I hope this can be rectified before it is
    included. PHP is inconsisent enough without adding more.
    If you talk about consistency, you should remember that right now no
    function and no feature in PHP relies on strict checking of primitive
    types.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Pierre Joye at Apr 17, 2008 at 5:08 pm
    Hi Stanislav,
    On Thu, Apr 17, 2008 at 7:02 PM, Stanislav Malyshev wrote:
    Hi!

    Your current implementation seems to be inconsistent with both itself
    and the rest of PHP. I hope this can be rectified before it is
    included. PHP is inconsisent enough without adding more.
    If you talk about consistency, you should remember that right now no
    function and no feature in PHP relies on strict checking of primitive types.
    Please try to minimize redundant response (at least within 15 mins). I
    think we all got that you are against type hints in PHP, that's plain
    wrong to do it, etc, etc. Thanks for your understanding (reply to my
    ICU questions instead :-D,

    Cheers,
  • Stanislav Malyshev at Apr 17, 2008 at 5:10 pm
    Hi!
    Please try to minimize redundant response (at least within 15 mins). I
    think we all got that you are against type hints in PHP, that's plain
    Against strict type hints, yes.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Paul Biggar at Apr 17, 2008 at 5:56 pm

    On Thu, Apr 17, 2008 at 7:02 PM, Stanislav Malyshev wrote:
    Your current implementation seems to be inconsistent with both itself
    and the rest of PHP. I hope this can be rectified before it is
    included. PHP is inconsisent enough without adding more.
    If you talk about consistency, you should remember that right now no
    function and no feature in PHP relies on strict checking of primitive types.
    That is not the case (or I am very much mistaken). In particular,
    is_int, which I mentioned in my email, is predicated on the IS_LONG
    type only.

    Paul


    --
    Paul Biggar
    paul.biggar@gmail.com
  • Stanislav Malyshev at Apr 17, 2008 at 6:24 pm
    Hi!
    If you talk about consistency, you should remember that right now no
    function and no feature in PHP relies on strict checking of primitive types.
    That is not the case (or I am very much mistaken). In particular,
    is_int, which I mentioned in my email, is predicated on the IS_LONG
    type only.
    Read that "no function except for a tiny handful of very special cases
    like is_* and serializes and probably one or two other functions that I
    forgot", ok?
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Paul Biggar at Apr 17, 2008 at 6:31 pm
    Hi,
    On Thu, Apr 17, 2008 at 8:22 PM, Stanislav Malyshev wrote:
    If you talk about consistency, you should remember that right now no
    function and no feature in PHP relies on strict checking of primitive
    types.
    That is not the case (or I am very much mistaken). In particular,
    is_int, which I mentioned in my email, is predicated on the IS_LONG
    type only.
    Read that "no function except for a tiny handful of very special cases like
    is_* and serializes and probably one or two other functions that I forgot",
    ok?

    is_* are the important functions, since they are the ones which most
    resemble the type hints under discussion. Up until now, anyone
    implementing this in user-land would use is_int(). It makes perfect
    sense that type hints should mimic this behaviour. Not doing so would
    be very inconsistent, and so confusing.


    Paul


    --
    Paul Biggar
    paul.biggar@gmail.com
  • Stanislav Malyshev at Apr 17, 2008 at 6:43 pm
    Hi!
    is_* are the important functions, since they are the ones which most
    resemble the type hints under discussion. Up until now, anyone
    Circular argument here.
    implementing this in user-land would use is_int(). It makes perfect
    No, you shouldn't do that - there's absolutely no reason to accept 1 and
    reject '1', unless you have some very rare and special circumstance. If
    you are using is_int for that, your code is wrong.
    sense that type hints should mimic this behaviour. Not doing so would
    be very inconsistent, and so confusing.
    Could we stop using word "consistent" to replace "I like it"?
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Pierre Joye at Apr 17, 2008 at 6:55 pm

    On Thu, Apr 17, 2008 at 8:41 PM, Stanislav Malyshev wrote:

    Circular argument here.
    No comment.

    Cheers,
  • Paul Biggar at Apr 17, 2008 at 7:43 pm

    On Thu, Apr 17, 2008 at 8:41 PM, Stanislav Malyshev wrote:
    is_* are the important functions, since they are the ones which most
    resemble the type hints under discussion. Up until now, anyone
    Circular argument here.
    Yes, I phrased that badly. I believe it is fair to say that there
    would be confusion over why is_int may fail after an 'int' type hint.
    More generally, I think it is difficult to explain why an int type
    hint does not guarantee an int.


    implementing this in user-land would use is_int(). It makes perfect
    No, you shouldn't do that - there's absolutely no reason to accept 1 and
    reject '1', unless you have some very rare and special circumstance. If you
    are using is_int for that, your code is wrong.
    That is very subjective. I doubt there is 'one true style' of PHP,
    despite suggestions I see about 'the PHP way'. But let us suppose you
    would use an int cast instead to ensure you have an int (by type, not
    coerced value). The behaviour I recommend is also consistent with
    casting. It would be syntactic sugar for

    function ($x) { $x = (int) ($x); ... }



    sense that type hints should mimic this behaviour. Not doing so would
    be very inconsistent, and so confusing.
    Could we stop using word "consistent" to replace "I like it"?
    I am very deliberately not using "consistent" to replace "I like it",
    except in the sense that I like consistency. It makes no sense to find
    that you do not have an int, when you specify you must. I very much
    mean consistency, and do not have a preference for the approach,
    except that only one seems perfectly consistent in this case, which is
    why I have recommended it.


    Paul

    --
    Paul Biggar
    paul.biggar@gmail.com
  • Derick Rethans at Apr 17, 2008 at 5:32 pm

    On Thu, 17 Apr 2008, Felipe Pena wrote:

    Now with both parameter and return value type hints.

    For parameter type hints, i have completed the actual implementation
    with the leftover php types:
    - string (binary string and unicode)
    - integer (accepting numeric string too)
    - double (accepting numeric string too)
    - boolean ('0', '1', true, false)
    I think that the typehints should be strict, if you don't want
    strictness, don't use type hints.

    regards,
    Derick
  • Mark van der Velden at Apr 17, 2008 at 6:48 pm

    Derick Rethans wrote:
    On Thu, 17 Apr 2008, Felipe Pena wrote:

    Now with both parameter and return value type hints.

    For parameter type hints, i have completed the actual implementation
    with the leftover php types:
    - string (binary string and unicode)
    - integer (accepting numeric string too)
    - double (accepting numeric string too)
    - boolean ('0', '1', true, false)
    I think that the typehints should be strict, if you don't want
    strictness, don't use type hints.
    +1

    - Mark
  • Stanislav Malyshev at Apr 17, 2008 at 6:54 pm

    I think that the typehints should be strict, if you don't want
    strictness, don't use type hints.
    Note that right now we already have non-strict typehints in most of the
    internal functions, so you *are* using them if you use PHP.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Jarismar Chaves da Silva at Apr 17, 2008 at 11:17 pm
    +1

    Derick Rethans wrote:
    On Thu, 17 Apr 2008, Felipe Pena wrote:

    Now with both parameter and return value type hints.

    For parameter type hints, i have completed the actual implementation
    with the leftover php types:
    - string (binary string and unicode)
    - integer (accepting numeric string too)
    - double (accepting numeric string too)
    - boolean ('0', '1', true, false)
    I think that the typehints should be strict, if you don't want
    strictness, don't use type hints.

    regards,
    Derick
    --

    *Jarismar Chaves da Silva, M.Sc.*

    *ADP**Labs** Brazil *
    jarismar_silva@adplabs.com.br
    http://www.adp.com
  • Arvids Godjuks at Apr 18, 2008 at 7:22 am
    +1 for strict types.

    That way it will be simple:
    * Don't need - then don't use at all
    * You need it - you use it fully.

    One thing than left to clearfy - do we allow to hint only part of args or do
    we go the road "if hint args, then hint them all!" (I'm personaly for second
    one - be strict)
  • Richard Quadling at Apr 18, 2008 at 11:33 am

    On 18/04/2008, Arvids Godjuks wrote:
    +1 for strict types.

    That way it will be simple:
    * Don't need - then don't use at all
    * You need it - you use it fully.

    One thing than left to clearfy - do we allow to hint only part of args or do
    we go the road "if hint args, then hint them all!" (I'm personaly for second
    one - be strict)
    It may be that a parameter CAN be mixed, so a lack of a type hint
    should be supported even if strict type hinting is used/implemented.
    Maybe a type hint of mixed?


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

    On Fri, 2008-04-18 at 12:33 +0100, Richard Quadling wrote:
    On 18/04/2008, Arvids Godjuks wrote:
    +1 for strict types.

    That way it will be simple:
    * Don't need - then don't use at all
    * You need it - you use it fully.

    One thing than left to clearfy - do we allow to hint only part of args or do
    we go the road "if hint args, then hint them all!" (I'm personaly for second
    one - be strict)
    It may be that a parameter CAN be mixed, so a lack of a type hint
    should be supported even if strict type hinting is used/implemented.
    Maybe a type hint of mixed?
    Of course; we don't make type hinting necessary, just type the variable
    name with no type hint as you would now and no type check is performed.
    --
    -----
    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 18, 2008 at 11:52 am

    Em Sex, 2008-04-18 às 10:22 +0300, Arvids Godjuks escreveu:
    +1 for strict types.

    That way it will be simple:
    * Don't need - then don't use at all
    * You need it - you use it fully.

    One thing than left to clearfy - do we allow to hint only part of args
    or do we go the road "if hint args, then hint them all!" (I'm
    personaly for second one - be strict)
    No, just use in the arg that you want.

    Example:
    http://felipe.ath.cx/diff/tests/param_tests/param_type_hint_016.phpt

    --
    Regards,
    Felipe Pena.
  • Marcus Boerger at May 25, 2008 at 8:28 am
    Hello Felipe,

    please do not allow non optional parameters after optional parameters.
    Also default value NULL seems pretty odd for a numeric type and it might
    be an idea to only allow types matching the type hint. But I guess it is
    in line the current type hints and a good solution to mark those as not
    passed.

    You took care of reflection parameter but not of reflection
    method/function.

    What I do not like about the return type hint patch is that it adds the
    native types upfront. This is actually all that is discussable. Return
    type hints themselves were already agreed on. That said we only need to
    think whether your syntax is ok. And from that perspective you get my
    vote, too. So how about a limited patch first that does not introduce
    native types, only implements return type hints and does also add
    reflection for it.

    marcus

    Friday, April 18, 2008, 1:52:22 PM, you wrote:
    Em Sex, 2008-04-18 às 10:22 +0300, Arvids Godjuks escreveu:
    +1 for strict types.

    That way it will be simple:
    * Don't need - then don't use at all
    * You need it - you use it fully.

    One thing than left to clearfy - do we allow to hint only part of args
    or do we go the road "if hint args, then hint them all!" (I'm
    personaly for second one - be strict)
    No, just use in the arg that you want.
    Example:
    http://felipe.ath.cx/diff/tests/param_tests/param_type_hint_016.phpt
    --
    Regards,
    Felipe Pena.




    Best regards,
    Marcus

Related Discussions

People

Translate

site design / logo © 2022 Grokbase