FAQ
There has been quite a bit of discussion on this list, IRC, developer
meetings, etc... about introduction of type hinting to PHP. Most
people appear to think that this would be a good idea, but there is a
reason why it is not in PHP already. The main source of conflict
appears to be that in some cases typical type hinting is just too
strict for PHP's typeless nature (most people expect that "1" == 1,
while int type hint would definitely reject string "1"). Personally,
I disagree with that opinion, but I can understand people who raise
that issue. At work we've been using PHP 5.2 with type hinting for
nearly 2 years now with great success, it makes code much easier to
read and understand and the security benefit of type hinting is not to
be under valued. In many cases type hinting can present a last line of
defense against unexpected input for numeric fields, which are
typically abused to do SQL injection.

I've taken a few hours this morning to port my 5.2 type hinting patch
to 5.3. In recognition of a need for a more 'flexible' numeric type
I've introduced (numeric) type hint that would allow bool/int/float
data types as well as a string containing a numeric entity as
identified by is_numeric_string(). For completion i've also added
(scalar) data type that will allow any scalar data element.

The patch is available here: http://ia.gd/patch/type_hint_53.txt

It should be noted that this patch is fully compatible with opcode
caches and and requires no changes on the part of an opcode cache such
as APC to work.

My hope is that the latest changes will allow this to become a
standard part of PHP.

Ilia Alshanetsky

P.S.

It should be noted that this is not the first idea for type hints,
that credit goes to Hannes Magnusson who had posted a similar patch on
the internals list back in 2006. Also, back in 2008 Felipe Pena wrote
a type hinting patch for PHP that is available on wiki.php.net.

Search Discussions

  • Gwynne Raskind at Jul 1, 2009 at 5:09 pm

    On Jul 1, 2009, at 12:59 PM, Ilia Alshanetsky wrote:
    There has been quite a bit of discussion on this list, IRC,
    developer meetings, etc... about introduction of type hinting to
    PHP. Most people appear to think that this would be a good idea, but
    there is a reason why it is not in PHP already. The main source of
    conflict appears to be that in some cases typical type hinting is
    just too strict for PHP's typeless nature (most people expect that
    "1" == 1, while int type hint would definitely reject string "1").
    Personally, I disagree with that opinion, but I can understand
    people who raise that issue. At work we've been using PHP 5.2 with
    type hinting for nearly 2 years now with great success, it makes
    code much easier to read and understand and the security benefit of
    type hinting is not to be under valued. In many cases type hinting
    can present a last line of defense against unexpected input for
    numeric fields, which are typically abused to do SQL injection. [snip]
    My hope is that the latest changes will allow this to become a
    standard part of PHP.
    +1 (+1000, actually :)

    -- Gwynne
  • Graham Kelly at Jul 1, 2009 at 5:22 pm
    This is great! I've always wanted to see optional type hinting for PHP.
    On Wed, Jul 1, 2009 at 10:09 AM, Gwynne Raskind wrote:
    On Jul 1, 2009, at 12:59 PM, Ilia Alshanetsky wrote:

    There has been quite a bit of discussion on this list, IRC, developer
    meetings, etc... about introduction of type hinting to PHP. Most people
    appear to think that this would be a good idea, but there is a reason why it
    is not in PHP already. The main source of conflict appears to be that in
    some cases typical type hinting is just too strict for PHP's typeless nature
    (most people expect that "1" == 1, while int type hint would definitely
    reject string "1"). Personally, I disagree with that opinion, but I can
    understand people who raise that issue. At work we've been using PHP 5.2
    with type hinting for nearly 2 years now with great success, it makes code
    much easier to read and understand and the security benefit of type hinting
    is not to be under valued. In many cases type hinting can present a last
    line of defense against unexpected input for numeric fields, which are
    typically abused to do SQL injection. [snip]
    My hope is that the latest changes will allow this to become a standard
    part of PHP.
    +1 (+1000, actually :)

    -- Gwynne



    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Alain Williams at Jul 1, 2009 at 5:15 pm

    On Wed, Jul 01, 2009 at 12:59:59PM -0400, Ilia Alshanetsky wrote:
    There has been quite a bit of discussion on this list, IRC, developer
    meetings, etc... about introduction of type hinting to PHP. Most
    people appear to think that this would be a good idea, but there is a
    reason why it is not in PHP already. The main source of conflict
    ...
    Another desirable result of type hinting is that it would strengthen
    reflection ... one use of that would be automatic generation of
    WSDL files. This is something that I am currently struggling to do,
    not helped by the completely cr*p documentation of this - I am not
    talking about PHP documentation here by W3 & other places :-(

    +1 to type hinting.

    --
    Alain Williams
    Linux/GNU 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
    Past chairman of UKUUG: http://www.ukuug.org/
    #include <std_disclaimer.h>
  • Tom Boutell at Jul 1, 2009 at 5:22 pm
    I expect this would be a problem for folks who are relying on the fact
    that they can parse configuration files and web inputs purely as
    strings, yet numeric fields containing string representations of
    numbers will actually behave as numbers if called upon to do so.

    Speaking of which, when I'm in a hurry and large numbers (or negative
    numbers) are not dangerous in that particular context, I sometimes
    validate a numeric field like this:

    $x = $_REQUEST['x'] + 0;

    And then assume $x will be a number - perhaps an obnoxious number,
    maybe even a huge floating point number with an exponent, but a
    number. Is there a flaw in that reasoning that I'm not aware of?

    On Wed, Jul 1, 2009 at 1:15 PM, Alain Williamswrote:
    On Wed, Jul 01, 2009 at 12:59:59PM -0400, Ilia Alshanetsky wrote:
    There has been quite a bit of discussion on this list, IRC, developer
    meetings, etc... about introduction of type hinting to PHP. Most
    people appear to think that this would be a good idea, but there is a
    reason why it is not in PHP already. The main source of conflict
    ...
    Another desirable result of type hinting is that it would strengthen
    reflection ... one use of that would be automatic generation of
    WSDL files. This is something that I am currently struggling to do,
    not helped by the completely cr*p documentation of this - I am not
    talking about PHP documentation here by W3 & other places :-(

    +1 to type hinting.

    --
    Alain Williams
    Linux/GNU 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
    Past 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


    --
    Tom Boutell
    P'unk Avenue
    215 755 1330
    punkave.com
    window.punkave.com
  • Ilia Alshanetsky at Jul 1, 2009 at 6:32 pm
    Tom,

    Type hinting is optional you don't have to use it. However, the
    "numeric" type I've added specifically addresses that point.

    Ilia Alshanetsky
    CIO/CSO
    Centah Inc.
    On 2009-07-01, at 1:22 PM, Tom Boutell wrote:

    I expect this would be a problem for folks who are relying on the fact
    that they can parse configuration files and web inputs purely as
    strings, yet numeric fields containing string representations of
    numbers will actually behave as numbers if called upon to do so.

    Speaking of which, when I'm in a hurry and large numbers (or negative
    numbers) are not dangerous in that particular context, I sometimes
    validate a numeric field like this:

    $x = $_REQUEST['x'] + 0;

    And then assume $x will be a number - perhaps an obnoxious number,
    maybe even a huge floating point number with an exponent, but a
    number. Is there a flaw in that reasoning that I'm not aware of?

    On Wed, Jul 1, 2009 at 1:15 PM, Alain Williamswrote:
    On Wed, Jul 01, 2009 at 12:59:59PM -0400, Ilia Alshanetsky wrote:
    There has been quite a bit of discussion on this list, IRC,
    developer
    meetings, etc... about introduction of type hinting to PHP. Most
    people appear to think that this would be a good idea, but there
    is a
    reason why it is not in PHP already. The main source of conflict
    ...
    Another desirable result of type hinting is that it would strengthen
    reflection ... one use of that would be automatic generation of
    WSDL files. This is something that I am currently struggling to do,
    not helped by the completely cr*p documentation of this - I am not
    talking about PHP documentation here by W3 & other places :-(

    +1 to type hinting.

    --
    Alain Williams
    Linux/GNU 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
    Past 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


    --
    Tom Boutell
    P'unk Avenue
    215 755 1330
    punkave.com
    window.punkave.com

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Zeev Suraski at Jul 5, 2009 at 8:29 am
    I think there's a more fundamental flaw here than just pointing to
    'numeric' as an alternative. The internal IS_* setting is
    meaningless for countless pieces of data floating around in PHP,
    arguably far more than the ones for which it truly represents the
    'semantic' type. Continuing what Stas said, it's no coincidence our
    internal functions transparently translate arguments to the required
    types (except for the rare cases where it's not possible).

    The other course of action is to change the implementation so that it
    behaves like the one for internal functions - with emphasis on
    conversion instead of validation of IS_*. We can consider being more
    strict - and error-out on non-numeric strings instead of producing
    0; If we were to start from scratch today, we'd probably do the same
    for internal functions. Encouraging the equivalent of strict is_*()
    checks is very inconsistent with both our entire internal functions
    library, as well as the common behavior of PHP. It doesn't come to
    say that it's not useful in some cases - but for these, using is_*()
    should be a suitable.

    Zeev

    At 20:40 01/07/2009, Ilia Alshanetsky wrote:
    Tom,

    Type hinting is optional you don't have to use it. However, the
    "numeric" type I've added specifically addresses that point.

    Ilia Alshanetsky
    CIO/CSO
    Centah Inc.
    On 2009-07-01, at 1:22 PM, Tom Boutell wrote:

    I expect this would be a problem for folks who are relying on the fact
    that they can parse configuration files and web inputs purely as
    strings, yet numeric fields containing string representations of
    numbers will actually behave as numbers if called upon to do so.

    Speaking of which, when I'm in a hurry and large numbers (or negative
    numbers) are not dangerous in that particular context, I sometimes
    validate a numeric field like this:

    $x = $_REQUEST['x'] + 0;

    And then assume $x will be a number - perhaps an obnoxious number,
    maybe even a huge floating point number with an exponent, but a
    number. Is there a flaw in that reasoning that I'm not aware of?

    On Wed, Jul 1, 2009 at 1:15 PM, Alain Williams<addw@phcomp.co.uk>
    wrote:
    On Wed, Jul 01, 2009 at 12:59:59PM -0400, Ilia Alshanetsky wrote:
    There has been quite a bit of discussion on this list, IRC,
    developer
    meetings, etc... about introduction of type hinting to PHP. Most
    people appear to think that this would be a good idea, but there
    is a
    reason why it is not in PHP already. The main source of conflict
    ...
    Another desirable result of type hinting is that it would strengthen
    reflection ... one use of that would be automatic generation of
    WSDL files. This is something that I am currently struggling to do,
    not helped by the completely cr*p documentation of this - I am not
    talking about PHP documentation here by W3 & other places :-(

    +1 to type hinting.

    --
    Alain Williams
    Linux/GNU 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
    Past 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


    --
    Tom Boutell
    P'unk Avenue
    215 755 1330
    punkave.com
    window.punkave.com

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Alain Williams at Jul 5, 2009 at 8:51 am

    On Sun, Jul 05, 2009 at 11:30:28AM +0300, Zeev Suraski wrote:
    I think there's a more fundamental flaw here than just pointing to
    'numeric' as an alternative. The internal IS_* setting is
    meaningless for countless pieces of data floating around in PHP,
    arguably far more than the ones for which it truly represents the
    'semantic' type. Continuing what Stas said, it's no coincidence our
    internal functions transparently translate arguments to the required
    types (except for the rare cases where it's not possible).

    The other course of action is to change the implementation so that it
    behaves like the one for internal functions - with emphasis on
    conversion instead of validation of IS_*. We can consider being more
    strict - and error-out on non-numeric strings instead of producing
    0; If we were to start from scratch today, we'd probably do the same
    for internal functions. Encouraging the equivalent of strict is_*()
    Maybe that is something to consider:

    PHP 6: warn on non-numeric strings, dependent on something in php.ini
    PHP 7: error on non-numeric strings

    If someone has some code that goes:
    $six = 3 + 'three';
    then is isn't doing what they intend, so an error would be helpful.

    The question is one of transition - breaking code that doesn't do input
    validation, hence for a transition to help the better programmers.
    As for the cr*p programmers - well their code was broken anyway.
    checks is very inconsistent with both our entire internal functions
    library, as well as the common behavior of PHP. It doesn't come to
    say that it's not useful in some cases - but for these, using is_*()
    should be a suitable.
    --
    Alain Williams
    Linux/GNU 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
    Past chairman of UKUUG: http://www.ukuug.org/
    #include <std_disclaimer.h>
  • Graham Kelly at Jul 1, 2009 at 5:22 pm
    It also makes type analysis for potential compile time optimizations much
    easier. It reduces the unknowns that occure from functions! This is
    something that could be a big help with that.
    On Wed, Jul 1, 2009 at 10:15 AM, Alain Williams wrote:
    On Wed, Jul 01, 2009 at 12:59:59PM -0400, Ilia Alshanetsky wrote:
    There has been quite a bit of discussion on this list, IRC, developer
    meetings, etc... about introduction of type hinting to PHP. Most
    people appear to think that this would be a good idea, but there is a
    reason why it is not in PHP already. The main source of conflict
    ...
    Another desirable result of type hinting is that it would strengthen
    reflection ... one use of that would be automatic generation of
    WSDL files. This is something that I am currently struggling to do,
    not helped by the completely cr*p documentation of this - I am not
    talking about PHP documentation here by W3 & other places :-(

    +1 to type hinting.

    --
    Alain Williams
    Linux/GNU 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
    Past chairman of UKUUG: http://www.ukuug.org/
    #include <http://www.ukuug.org/%0A#include> <std_disclaimer.h>

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Sebastian Bergmann at Jul 1, 2009 at 5:17 pm

    Ilia Alshanetsky schrieb:
    about introduction of type hinting to PHP
    About the "introduction of scalar type hinting" you mean? :-)

    I am all for this, but I think it would be wrong to add this in 5.3.X.

    --
    Sebastian Bergmann Co-Founder and Principal Consultant
    http://sebastian-bergmann.de/ http://thePHP.cc/
  • Tom Boutell at Jul 1, 2009 at 5:23 pm
    Yes 5.3.1 is definitely not the right time frame for a backwards
    incompatible change.

    On Wed, Jul 1, 2009 at 1:17 PM, Sebastian
    Bergmannwrote:
    Ilia Alshanetsky schrieb:
    about introduction of type hinting to PHP
    About the "introduction of scalar type hinting" you mean? :-)

    I am all for this, but I think it would be wrong to add this in 5.3.X.

    --
    Sebastian Bergmann                    Co-Founder and Principal Consultant
    http://sebastian-bergmann.de/                           http://thePHP.cc/


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


    --
    Tom Boutell
    P'unk Avenue
    215 755 1330
    punkave.com
    window.punkave.com
  • Paul Biggar at Jul 1, 2009 at 5:24 pm
    Hi Ilia,

    This is great.

    On Wed, Jul 1, 2009 at 5:59 PM, Ilia Alshanetskywrote:
    I've taken a few hours this morning to port my 5.2 type hinting patch to
    5.3. In recognition of a need for a more 'flexible' numeric type I've
    introduced (numeric) type hint that would allow bool/int/float data types as
    well as a string containing a numeric entity as identified by
    is_numeric_string(). For completion i've also added (scalar) data type that
    will allow any scalar data element.
    I think this will go a long way to addressing people's concerns when
    this came up previously.

    The patch is available here: http://ia.gd/patch/type_hint_53.txt
    I presume the idea is that some people (if they so chose) would want
    to type hint every parameter in their program. To facilitate this, I
    might suggest a "mixed" hint (like in the docs), and a null hint
    (though I'm not sure if it would be called "null" or "unset" or both).


    Finally, I don't want to ruin this, but last time there was
    disagreement over whether numbers should be coerced to the specified
    types, or left alone. What does your patch do?

    ie function x (int $x) { echo is_int ($x); } x ("5");



    Thanks,
    Paul

    It should be noted that this is not the first idea for type hints, that
    credit goes to Hannes Magnusson who had posted a similar patch on the
    internals list back in 2006. Also, back in 2008 Felipe Pena wrote a type
    hinting patch for PHP that is available on wiki.php.net.
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Paul Biggar
    paul.biggar@gmail.com
  • Matt Wilson at Jul 1, 2009 at 6:05 pm
    +1000 * infinity plus one
    On Jul 1, 2009, at 12:23 PM, Paul Biggar wrote:

    Hi Ilia,

    This is great.

    On Wed, Jul 1, 2009 at 5:59 PM, Ilia Alshanetskywrote:
    I've taken a few hours this morning to port my 5.2 type hinting
    patch to
    5.3. In recognition of a need for a more 'flexible' numeric type I've
    introduced (numeric) type hint that would allow bool/int/float data
    types as
    well as a string containing a numeric entity as identified by
    is_numeric_string(). For completion i've also added (scalar) data
    type that
    will allow any scalar data element.
    I think this will go a long way to addressing people's concerns when
    this came up previously.

    The patch is available here: http://ia.gd/patch/type_hint_53.txt
    I presume the idea is that some people (if they so chose) would want
    to type hint every parameter in their program. To facilitate this, I
    might suggest a "mixed" hint (like in the docs), and a null hint
    (though I'm not sure if it would be called "null" or "unset" or both).


    Finally, I don't want to ruin this, but last time there was
    disagreement over whether numbers should be coerced to the specified
    types, or left alone. What does your patch do?

    ie function x (int $x) { echo is_int ($x); } x ("5");



    Thanks,
    Paul

    It should be noted that this is not the first idea for type hints,
    that
    credit goes to Hannes Magnusson who had posted a similar patch on the
    internals list back in 2006. Also, back in 2008 Felipe Pena wrote a
    type
    hinting patch for PHP that is available on wiki.php.net.
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Paul Biggar
    paul.biggar@gmail.com

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Ilia Alshanetsky at Jul 1, 2009 at 6:32 pm
    If you use int type hit "1" will be rejected, but if use numeric type
    hint it will be accepted.

    Ilia Alshanetsky

    On 2009-07-01, at 1:23 PM, Paul Biggar wrote:

    Hi Ilia,

    This is great.

    On Wed, Jul 1, 2009 at 5:59 PM, Ilia Alshanetskywrote:
    I've taken a few hours this morning to port my 5.2 type hinting
    patch to
    5.3. In recognition of a need for a more 'flexible' numeric type I've
    introduced (numeric) type hint that would allow bool/int/float data
    types as
    well as a string containing a numeric entity as identified by
    is_numeric_string(). For completion i've also added (scalar) data
    type that
    will allow any scalar data element.
    I think this will go a long way to addressing people's concerns when
    this came up previously.

    The patch is available here: http://ia.gd/patch/type_hint_53.txt
    I presume the idea is that some people (if they so chose) would want
    to type hint every parameter in their program. To facilitate this, I
    might suggest a "mixed" hint (like in the docs), and a null hint
    (though I'm not sure if it would be called "null" or "unset" or both).


    Finally, I don't want to ruin this, but last time there was
    disagreement over whether numbers should be coerced to the specified
    types, or left alone. What does your patch do?

    ie function x (int $x) { echo is_int ($x); } x ("5");



    Thanks,
    Paul

    It should be noted that this is not the first idea for type hints,
    that
    credit goes to Hannes Magnusson who had posted a similar patch on the
    internals list back in 2006. Also, back in 2008 Felipe Pena wrote a
    type
    hinting patch for PHP that is available on wiki.php.net.
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Paul Biggar
    paul.biggar@gmail.com
  • Stanislav Malyshev at Jul 1, 2009 at 6:07 pm
    Hi!
    The patch is available here: http://ia.gd/patch/type_hint_53.txt
    Technical comment: as this patch changes binary API this shouldn't
    happen in 5.3 branch. So maybe it's better to make it for 6.

    As for the idea itself, it is obvious that many people like it, I would
    just note that it would produce a confusion for some people due to the
    fact that true, 1, 1.0, b'1' and '1' now become incompatible values and
    (once you start using typehints, of course) you'd have to explicitly
    convert them. That would lead people to stuff their code with explicit
    type conversions, which doesn't add to code cleanness. This also means
    that internal functions and user functions would behave differently with
    regard to type conversions.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Ilia Alshanetsky at Jul 1, 2009 at 6:32 pm
    As far as your point goes, numeric hint addresses it.

    Ilia Alshanetsky
    CIO/CSO
    Centah Inc.
    On 2009-07-01, at 2:07 PM, Stanislav Malyshev wrote:

    Hi!
    The patch is available here: http://ia.gd/patch/type_hint_53.txt
    Technical comment: as this patch changes binary API this shouldn't
    happen in 5.3 branch. So maybe it's better to make it for 6.

    As for the idea itself, it is obvious that many people like it, I
    would just note that it would produce a confusion for some people
    due to the fact that true, 1, 1.0, b'1' and '1' now become
    incompatible values and (once you start using typehints, of course)
    you'd have to explicitly convert them. That would lead people to
    stuff their code with explicit type conversions, which doesn't add
    to code cleanness. This also means that internal functions and user
    functions would behave differently with regard to type conversions.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Stanislav Malyshev at Jul 1, 2009 at 6:44 pm
    Hi!
    As far as your point goes, numeric hint addresses it.
    Numeric hint addresses one scenario only. It doesn't address conversions
    to strings or booleans, for example (even C allows you to use int as
    boolean! :).
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Paul Biggar at Jul 1, 2009 at 6:53 pm

    On Wed, Jul 1, 2009 at 7:44 PM, Stanislav Malyshevwrote:
    Hi!
    As far as your point goes, numeric hint addresses it.
    Numeric hint addresses one scenario only. It doesn't address conversions to
    strings or booleans, for example (even C allows you to use int as boolean!
    :).
    I agree. We won't be able to use an int type for something which
    should take an int. That might not matter in user code, but if we
    cannot actually type hint internals functions then its a problem.

    I think it should be a requirement that internals functions should be
    able to be type hinted using what the manual says. We don't need to be
    too strict on that, but if that manual says int, it should be hintable
    with int, and accept "1".

    My feeling is that scalars should be automatically coerced to the
    correct type, if it makes sense to do so. (ie reject non-numeric
    strings for ints).

    Thanks,
    Paul



    --
    Paul Biggar
    paul.biggar@gmail.com
  • Stanislav Malyshev at Jul 1, 2009 at 7:04 pm
    Hi!
    I agree. We won't be able to use an int type for something which
    should take an int. That might not matter in user code, but if we
    cannot actually type hint internals functions then its a problem.
    Internal functions have types, however parameters of different types are
    usually converted, not rejected.
    My feeling is that scalars should be automatically coerced to the
    correct type, if it makes sense to do so. (ie reject non-numeric
    That (coercion) is what internal functions do, but not what the proposed
    patch does (except for "numeric" hint).
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Paul Biggar at Jul 1, 2009 at 7:12 pm

    On Wed, Jul 1, 2009 at 8:04 PM, Stanislav Malyshevwrote:
    I agree. We won't be able to use an int type for something which
    should take an int. That might not matter in user code, but if we
    cannot actually type hint internals functions then its a problem.
    Internal functions have types, however parameters of different types are
    usually converted, not rejected.
    Yes, rejection is bad. Coercion is good. (Silently accepting is bad).

    My feeling is that scalars should be automatically coerced to the
    correct type, if it makes sense to do so. (ie reject non-numeric
    That (coercion) is what internal functions do, but not what the proposed
    patch does (except for "numeric" hint).
    Right. I think we're arguing on the same side. I'm just saying that if
    the manual says 'int', we should be able to use int, and not be
    required to use 'numeric'.


    Thanks,
    Paul




    --
    Paul Biggar
    paul.biggar@gmail.com
  • Ilia Alshanetsky at Jul 1, 2009 at 8:27 pm
    C does not have booleans, they are emulated via smallint/tinyint. As
    far as your other message goes, this patch does nothing to affect how
    native functions handle args.

    Ilia Alshanetsky

    On 2009-07-01, at 2:44 PM, Stanislav Malyshev wrote:

    Hi!
    As far as your point goes, numeric hint addresses it.
    Numeric hint addresses one scenario only. It doesn't address
    conversions to strings or booleans, for example (even C allows you
    to use int as boolean! :).
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Stanislav Malyshev at Jul 1, 2009 at 8:29 pm
    Hi!
    C does not have booleans, they are emulated via smallint/tinyint. As far
    as your other message goes, this patch does nothing to affect how native
    functions handle args.
    Right. So we would have two APIs for types - one coercing (for
    internals) and one strict (for user functions), which would work in
    entirely different way. Is that good?
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Hannes Magnusson at Jul 1, 2009 at 8:42 pm

    On Wed, Jul 1, 2009 at 22:29, Stanislav Malyshevwrote:
    Hi!
    C does not have booleans, they are emulated via smallint/tinyint. As far
    as your other message goes, this patch does nothing to affect how native
    functions handle args.
    Right. So we would have two APIs for types - one coercing (for internals)
    and one strict (for user functions), which would work in entirely different
    way. Is that good?
    How is that different from what we have already?

    Internally you type hint (arginfo) what you want, in userland you'll
    be able to do that too (int $foo).

    Internally you parse arguments (param parsing, casting), in userland
    you do that already (function fo($var) {$var = (string)$var})


    I don't understand what "work entirely different" you are talking
    about. This is how PHP already works.

    -Hannes
  • Stanislav Malyshev at Jul 1, 2009 at 8:50 pm
    Hi!
    Right. So we would have two APIs for types - one coercing (for internals)
    and one strict (for user functions), which would work in entirely different
    way. Is that good?
    How is that different from what we have already?
    Well, it's different in a way that right now we have typehints only for
    classes and arrays (which work the same internal and external) and
    conversions for internals and some places user code (which use the same
    logic, just in user code you can't apply them to function parameters
    automatically).
    With this patch, we won't have one logic anymore - we'd have two logics
    - one for typehinted functions (reject everything that doesn't match the
    type) and one for the rest of the language (try to coerce types). Two
    logics in one language is usually not good.
    Internally you type hint (arginfo) what you want, in userland you'll
    be able to do that too (int $foo).
    No, internal typehint doesn't work the way "int" typehint works with
    this patch. Internal typehint (zend_parse_parameters) do conversions,
    see zend_API.c. Only typehint that would resemble what internals do is
    "numeric" (well, and "scalar", but it doesn't really have internal
    counterpart).
    I don't understand what "work entirely different" you are talking
    about. This is how PHP already works.
    No, that's exactly how PHP _doesn't_ work - there's always type
    coercion, not just matching of zval types.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Hannes Magnusson at Jul 1, 2009 at 9:02 pm

    On Wed, Jul 1, 2009 at 22:50, Stanislav Malyshevwrote:
    No, internal typehint doesn't work the way "int" typehint works with this
    patch. Internal typehint (zend_parse_parameters) do conversions, see
    You are wrong. Internal type hinting is done in the form of argument
    information.
    Those are identical to the userspace type hinting.

    ZEND_BEGIN_ARG_INFO(arginfo_foo, 0)
    ZEND_ARG_OBJ_INFO(0, MyClass, argumentName, 0)
    ZEND_END_ARG_INFO();

    is the same as the userspace form of:

    function foo(MyClass $argumentName) {}

    The current patch is missing a ZEND_ARG_STRING_INFO(0, argumentName,
    0) which would be the same as
    fnuction foo(string $argumentName){}
    If that is the onlything you are worrying about then thats easily fixed.


    zend_parse_parameters(... abcdefg)
    is the same as
    function($a, $b, $c..) { $a = (int) $a; $b = (string) $b; $c = (array) $c...}


    -Hannes
  • Paul Biggar at Jul 1, 2009 at 9:08 pm

    On Wed, Jul 1, 2009 at 10:02 PM, Hannes Magnussonwrote:
    On Wed, Jul 1, 2009 at 22:50, Stanislav Malyshevwrote:
    No, internal typehint doesn't work the way "int" typehint works with this
    patch. Internal typehint (zend_parse_parameters) do conversions, see
    You are wrong. Internal type hinting is done in the form of argument
    information.
    Those are identical to the userspace type hinting.

    ZEND_BEGIN_ARG_INFO(arginfo_foo, 0)
    ZEND_ARG_OBJ_INFO(0, MyClass, argumentName, 0)
    ZEND_END_ARG_INFO();

    is the same as the userspace form of:

    function foo(MyClass $argumentName) {}

    The current patch is missing a ZEND_ARG_STRING_INFO(0, argumentName,
    0) which would be the same as
    fnuction foo(string $argumentName){}
    If that is the onlything you are worrying about then thats easily fixed.


    zend_parse_parameters(... abcdefg)
    is the same as
    function($a, $b, $c..) { $a = (int) $a; $b = (string) $b; $c = (array) $c...}

    So, what you're saying is, the patch already handles coercion? If
    that's the case, then problem solved.

    (But I didnt think it did.)

    Thanks,
    Paul


    --
    Paul Biggar
    paul.biggar@gmail.com
  • Hannes Magnusson at Jul 1, 2009 at 9:23 pm

    On Wed, Jul 1, 2009 at 23:07, Paul Biggarwrote:
    So, what you're saying is, the patch already handles coercion? If
    that's the case, then problem solved.
    The patch offers scalar type _hinting_. Not type _casting_.

    Type hinting in PHP works very simply: If the value doesn't type-match
    the argument information (arginfo internally) then it will be rejected
    and E_RECOVERABLE_ERROR thrown.

    In most circumstances that error is fatal. However. If the user
    chooses then he can ignore that error (by creating his own error
    handler) and continue the execution.

    Type _hinting_ is in no way related to type _casting_.


    Furthermore, the patch introduces couple of new types, "scalar" and
    "numeric". These are "magic types" and do value-to-real-type
    comparison. No type casting.
    The scalar type hint accepts strings, booleans, ints and floats.
    The numeric type hint accepts strings (that pass is_numeric()),
    booleans, ints and floats.


    -Hannes
  • Paul Biggar at Jul 1, 2009 at 9:37 pm

    On Wed, Jul 1, 2009 at 10:23 PM, Hannes Magnussonwrote:
    On Wed, Jul 1, 2009 at 23:07, Paul Biggarwrote:
    So, what you're saying is, the patch already handles coercion? If
    that's the case, then problem solved.
    The patch offers scalar type _hinting_. Not type _casting_.

    Type hinting in PHP works very simply: If the value doesn't type-match
    the argument information (arginfo internally) then it will be rejected
    and E_RECOVERABLE_ERROR thrown.

    In most circumstances that error is fatal. However. If the user
    chooses then he can ignore that error (by creating his own error
    handler) and continue the execution.

    Type _hinting_ is in no way related to type _casting_.

    It should be.

    The current type hinting is for objects, which in PHP are strongly
    typed. We plan to extend it to scalars, which in PHP are weakly typed.
    Adding a strong type system for scalars goes against the rest of the
    language.

    As Stas said:
    With this patch, we won't have one logic anymore - we'd have two logics - one for typehinted functions (reject everything that doesn't match the type) and one for the rest of the language (try to coerce
    types). Two logics in one language is usually not good.
    PHP already has 2 type systems. I don't think that adding a 3rd one is
    complementary.


    Furthermore, the patch introduces couple of new types, "scalar" and
    "numeric". These are "magic types" and do value-to-real-type
    comparison. No type casting.
    The scalar type hint accepts strings, booleans, ints and floats.
    The numeric type hint accepts strings (that pass is_numeric()),
    booleans, ints and floats.

    Yes. Therefore only the scalar and numeric types are useful. Nobody
    wants to use an 'int' hint that fails on numeric strings.

    Also, I don't know what happens for string hints when you pass an
    object with a __toString handler, but it should be allowed.


    Thanks,
    Paul

    --
    Paul Biggar
    paul.biggar@gmail.com
  • Hannes Magnusson at Jul 1, 2009 at 9:53 pm

    On Wed, Jul 1, 2009 at 23:36, Paul Biggarwrote:
    On Wed, Jul 1, 2009 at 10:23 PM, Hannes
    Magnussonwrote:
    On Wed, Jul 1, 2009 at 23:07, Paul Biggarwrote:
    So, what you're saying is, the patch already handles coercion? If
    that's the case, then problem solved.
    The patch offers scalar type _hinting_. Not type _casting_.

    Type hinting in PHP works very simply: If the value doesn't type-match
    the argument information (arginfo internally) then it will be rejected
    and E_RECOVERABLE_ERROR thrown.

    In most circumstances that error is fatal. However. If the user
    chooses then he can ignore that error (by creating his own error
    handler) and continue the execution.

    Type _hinting_ is in no way related to type _casting_.

    It should be.
    function foo(string $str, array $arr) {}

    foo(false, "foobar");

    You are saying that the first argument should be casted, but not the second?
    Or are you planning on breaking pretty much every single application using PHP5?

    Furthermore, the patch introduces couple of new types, "scalar" and
    "numeric". These are "magic types" and do value-to-real-type
    comparison. No type casting.
    The scalar type hint accepts strings, booleans, ints and floats.
    The numeric type hint accepts strings (that pass is_numeric()),
    booleans, ints and floats.

    Yes. Therefore only the scalar and numeric types are useful. Nobody
    wants to use an 'int' hint that fails on numeric strings.
    I do. I don't only deal with $_REQUEST stuff.
    I don't have the resources to go the Y! route. I write bunch of stuff
    in PHP. Real type hinting would help _alot_.



    Also, I don't know what happens for string hints when you pass an
    object with a __toString handler, but it should be allowed.
    Apply the patch and try?
    It would be neat if people would do a quick readthrough the patch
    before arguing against it :)

    -Hannes
  • Paul Biggar at Jul 1, 2009 at 10:08 pm

    On Wed, Jul 1, 2009 at 10:53 PM, Hannes Magnussonwrote:
    On Wed, Jul 1, 2009 at 23:36, Paul Biggarwrote:
    On Wed, Jul 1, 2009 at 10:23 PM, Hannes
    Magnussonwrote:
    On Wed, Jul 1, 2009 at 23:07, Paul Biggarwrote:
    So, what you're saying is, the patch already handles coercion? If
    that's the case, then problem solved.
    The patch offers scalar type _hinting_. Not type _casting_.

    Type hinting in PHP works very simply: If the value doesn't type-match
    the argument information (arginfo internally) then it will be rejected
    and E_RECOVERABLE_ERROR thrown.

    In most circumstances that error is fatal. However. If the user
    chooses then he can ignore that error (by creating his own error
    handler) and continue the execution.

    Type _hinting_ is in no way related to type _casting_.

    It should be.
    function foo(string $str, array $arr) {}

    foo(false, "foobar");

    You are saying that the first argument should be casted, but not the second?
    Or are you planning on breaking pretty much every single application using PHP5?
    I'm sorry, I don't see what you're saying?


    Yes. Therefore only the scalar and numeric types are useful. Nobody
    wants to use an 'int' hint that fails on numeric strings.
    I do. I don't only deal with $_REQUEST stuff.
    I don't have the resources to go the Y! route. I write bunch of stuff
    in PHP. Real type hinting would help _alot_.
    My point is that type hints should be like what we've been using for
    years in the docs.

    There is obviously a tension here. People want two different features.
    I'm not sure I see a way to reconcile that (unless you'd like 'strict
    int' or 'is int'?)



    Also, I don't know what happens for string hints when you pass an
    object with a __toString handler, but it should be allowed.
    Apply the patch and try?
    It would be neat if people would do a quick readthrough the patch
    before arguing against it :)
    I did of course read the patch. I ask questions the way I do to avoid
    confrontation, which is all too prevalent on this list.

    I wanted to know what the code was intended to do, not what it does.
    The patch wasnt clear without context, and it had no comments or
    tests.

    (FYI, I did a fairly detailed review of the type hinting patch last
    year, which was ignored, so I'm reluctant to put the same effort in
    here).


    Thanks,
    Paul



    --
    Paul Biggar
    paul.biggar@gmail.com
  • Stanislav Malyshev at Jul 1, 2009 at 10:07 pm
    Hi!
    Type _hinting_ is in no way related to type _casting_.
    If you define it as such, there's no scalar type _hinting_ in PHP at all
    now. All engine works through _casting_.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Stanislav Malyshev at Jul 1, 2009 at 10:05 pm
    Hi!
    You are wrong. Internal type hinting is done in the form of argument
    information.
    You are confusing arginfo's with zend_parse_parameters types. They work
    differently (class typehints are strict, because there's no way to
    convert classes from one type to another). These aren't even the same
    types - all objects have the same internal type, IS_OBJECT, so it works
    on entirely different level.
    The current patch is missing a ZEND_ARG_STRING_INFO(0, argumentName,
    0) which would be the same as
    fnuction foo(string $argumentName){}
    That doesn't exist and wouldn't exist for currently available functions
    since making internal functions do that (strict type matching) would be
    a huge code breakage.
    zend_parse_parameters(... abcdefg)
    is the same as
    function($a, $b, $c..) { $a = (int) $a; $b = (string) $b; $c = (array) $c...}
    Now it is, but that's not the way typehints work in the proposed patch.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Richard Quadling at Jul 2, 2009 at 12:26 pm

    2009/7/1 Stanislav Malyshev <stas@zend.com>:
    Hi!
    The patch is available here: http://ia.gd/patch/type_hint_53.txt
    Technical comment: as this patch changes binary API this shouldn't happen in
    5.3 branch. So maybe it's better to make it for 6.

    As for the idea itself, it is obvious that many people like it, I would just
    note that it would produce a confusion for some people due to the fact that
    true, 1, 1.0, b'1' and '1' now become incompatible values and (once you
    start using typehints, of course) you'd have to explicitly convert them.
    That would lead people to stuff their code with explicit type conversions,
    which doesn't add to code cleanness. This also means that internal functions
    and user functions would behave differently with regard to type conversions.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com   http://www.zend.com/
    (408)253-8829   MSN: stas@zend.com

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    Doesn't "stuff their code with explicit type conversions" actually
    mean "perform appropriate validation and conversion on incoming data"
    ?

    The majority of data that a program gets is either from a DB (and if
    ALL your columns are varchars, well, I give up and a xxx_fetch_row
    SHOULD cast to an appropriate type in my mind, but ...), from a config
    file (normally all strings), $_xxx (normally all strings). Internal
    values are inherently cast. How many people write ...

    $some_boolean = "1"; // Set some_boolean flag to true.

    No, they write ...

    $some_boolean = true; // No need to document anything here as the code
    is pretty much speaking for itself.


    We are constantly told about GIGO and not accepting anything a user
    supplies as safe, so, with that in mind, you validate the incoming
    data (one way is to cast to the valid type and then check ranges,
    etc.) and from then on everything is in the appropriate type.

    PHP's type juggling is useful, without a doubt.

    But it seems to be limited to 2 areas.

    1 - Casting to strings for output.
    2 - Casting to boolean for equality testing.


    So they don't "perform appropriate validation and conversion on
    incoming data", then you will end up with having to "stuff their code
    with explicit type conversions".

    That's something I'm prepared to live with.

    So.

    A big +1 from me to incorporate type hinting into PHP.

    Regards,

    Richard Quadling.
    --
    -----
    Richard Quadling
    Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
    "Standing on the shoulders of some very clever giants!"
    I need a car : http://snipurl.com/l4pih
    ZOPA : http://uk.zopa.com/member/RQuadling
  • Stanislav Malyshev at Jul 2, 2009 at 4:59 pm
    Hi!
    Doesn't "stuff their code with explicit type conversions" actually
    mean "perform appropriate validation and conversion on incoming data"
    ?
    Sometimes it does, but in many cases it doesn't - since variables are
    not typed and types can be juggled, you'd have to take precautions even
    though you could be sure the value itself is sanitized.
    We are constantly told about GIGO and not accepting anything a user
    supplies as safe, so, with that in mind, you validate the incoming
    It's not about the user input and security - it's about having different
    parts of your code working together through all possible changes. If
    you've got strict API you've got to make sure what you are sending to it
    would pass those strict checks, and would keep doing so through all
    changes done to the code.
    A big +1 from me to incorporate type hinting into PHP.
    I think calling this proposal "type hinting" just confuses the
    discussion. It's (optional) strict typing and it should be called so.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Alain Williams at Jul 2, 2009 at 5:12 pm

    On Thu, Jul 02, 2009 at 09:59:43AM -0700, Stanislav Malyshev wrote:

    A big +1 from me to incorporate type hinting into PHP.
    I think calling this proposal "type hinting" just confuses the
    discussion. It's (optional) strict typing and it should be called so.
    +1

    But first we must fix the current PHP manual that refers to it as type hinting:

    http://www.php.net/manual/en/language.oop5.typehinting.php

    --
    Alain Williams
    Linux/GNU 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
    Past chairman of UKUUG: http://www.ukuug.org/
    #include <std_disclaimer.h>
  • Richard Quadling at Jul 3, 2009 at 9:41 am

    2009/7/2 Stanislav Malyshev <stas@zend.com>:
    It's not about the user input and security - it's about having different
    parts of your code working together through all possible changes. If you've
    got strict API you've got to make sure what you are sending to it would pass
    those strict checks, and would keep doing so through all changes done to the
    code.
    Hmm. Sounds like a programmers job you're describing there.

    I wonder if the split is between people coming to PHP from web design
    (JavaScript/Perl) and coming to PHP from other programming languages
    (VB/Java/C++/COBOL/ColdFusion - a long list [1]). I've mainly come
    from a Delphi's Object Pascal and Sage Retrieve 4GL (syntatically a
    mix of COBOL and Pascal).
    A big +1 from me to incorporate type hinting into PHP.
    I think calling this proposal "type hinting" just confuses the discussion.
    It's (optional) strict typing and it should be called so.
    Maybe this could be solved easier and made more acceptable to all
    sides if rather than calling it "type hinting" / "(optional) strict
    typing" it was called "auto casting".

    A significant issue is what happens when the variables supplied are
    NOT of the appropriate type. I agree with Stanislav in that developers
    could end up with having to "stuff their code with explicit type
    conversions".

    Inside the function/method, we are wanting to essentially force the
    inputs to match the requirements.

    So, rather than have the "explicit type conversions" being performed
    by users of the libraries, why not incorporate the conversions into
    the function/method declaration?

    If the data coming in is weakly typed, and we are wanting a specific
    type, we are going to cast it (currently). Casting is going to take
    place somewhere.

    Currently, you can use docblocks to suggest the type (no enforcement).

    If a user DOES read the docblocks and casts it, it doesn't actually
    help anyone as PHP is known to be weakly typed, so the library
    developer STILL has to do checks of some sort.

    But. If autocasting was available, users could RELY on the fact that
    PHP will use its built-in, well known and documented type-juggling
    logic to cast the supplied userland data to the libraries required
    type.

    This is now really utilising PHP's type-juggling to intelligently
    provide library developers with optional strict-typing. It
    incorporates type hinting, so a library user can do the casting if
    they want (I assume PHP does nothing for (string)"1" or (int)4, etc.)


    Essentially auto casting would remove having to manually cast data at all.


    Regards,

    Richard.


    [1] http://en.wikipedia.org/wiki/Comparison_of_programming_languages#Type_systems


    --
    -----
    Richard Quadling
    Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
    "Standing on the shoulders of some very clever giants!"
    I need a car : http://snipurl.com/l4pih
    ZOPA : http://uk.zopa.com/member/RQuadling
  • Stanislav Malyshev at Jul 3, 2009 at 10:40 pm
    Hi!
    I wonder if the split is between people coming to PHP from web design
    (JavaScript/Perl) and coming to PHP from other programming languages
    (VB/Java/C++/COBOL/ColdFusion - a long list [1]). I've mainly come
    I've learned Java in about '96 and Perl around the same time. I wonder
    which box you'd want to put me in :)
    Maybe this could be solved easier and made more acceptable to all
    sides if rather than calling it "type hinting" / "(optional) strict
    typing" it was called "auto casting".
    But as proposed it's not casting, unlike (string) - which is casting -
    it would just reject the variable that is not string, without any
    attempt to convert type. It's strict typing, just like C or Java do.
    So, rather than have the "explicit type conversions" being performed
    by users of the libraries, why not incorporate the conversions into
    the function/method declaration?
    That's what I was saying from the start. :)
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Paul Biggar at Jul 3, 2009 at 1:31 pm
    Hi Ilia,

    On Wed, Jul 1, 2009 at 7:07 PM, Stanislav Malyshevwrote:
    The patch is available here: http://ia.gd/patch/type_hint_53.txt
    Technical comment: as this patch changes binary API this shouldn't happen in
    5.3 branch. So maybe it's better to make it for 6.

    Index: Zend/zend_compile.h
    ===================================================================
    RCS file: /repository/ZendEngine2/zend_compile.h,v
    retrieving revision 1.316.2.8.2.12.2.40
    diff -u -p -a -d -u -r1.316.2.8.2.12.2.40 zend_compile.h
    --- Zend/zend_compile.h 5 Jun 2009 23:20:59 -0000 1.316.2.8.2.12.2.40
    +++ Zend/zend_compile.h 1 Jul 2009 16:45:02 -0000
    @@ -175,7 +175,7 @@ typedef struct _zend_arg_info {
    zend_uint name_len;
    const char *class_name;
    zend_uint class_name_len;
    - zend_bool array_type_hint;
    + zend_uint type_hint;
    zend_bool allow_null;
    zend_bool pass_by_reference;
    zend_bool return_reference;


    I think you could make this work for 5.3, if it used the old
    "zend_bool array_type_hint". A zend_bool is 8 bits, so that's plenty.
    It would be a little bit messy, but I'm fairly confident it could be
    made work.


    Thanks,
    Paul



    --
    Paul Biggar
    paul.biggar@gmail.com
  • Ilia Alshanetsky at Jul 3, 2009 at 1:35 pm
    Good point, this way API could remain the same.
    On 3-Jul-09, at 9:31 AM, Paul Biggar wrote:

    Hi Ilia,

    On Wed, Jul 1, 2009 at 7:07 PM, Stanislav Malyshevwrote:
    The patch is available here: http://ia.gd/patch/type_hint_53.txt
    Technical comment: as this patch changes binary API this shouldn't
    happen in
    5.3 branch. So maybe it's better to make it for 6.

    Index: Zend/zend_compile.h
    ===================================================================
    RCS file: /repository/ZendEngine2/zend_compile.h,v
    retrieving revision 1.316.2.8.2.12.2.40
    diff -u -p -a -d -u -r1.316.2.8.2.12.2.40 zend_compile.h
    --- Zend/zend_compile.h 5 Jun 2009 23:20:59 -0000 1.316.2.8.2.12.2.40
    +++ Zend/zend_compile.h 1 Jul 2009 16:45:02 -0000
    @@ -175,7 +175,7 @@ typedef struct _zend_arg_info {
    zend_uint name_len;
    const char *class_name;
    zend_uint class_name_len;
    - zend_bool array_type_hint;
    + zend_uint type_hint;
    zend_bool allow_null;
    zend_bool pass_by_reference;
    zend_bool return_reference;


    I think you could make this work for 5.3, if it used the old
    "zend_bool array_type_hint". A zend_bool is 8 bits, so that's plenty.
    It would be a little bit messy, but I'm fairly confident it could be
    made work.


    Thanks,
    Paul



    --
    Paul Biggar
    paul.biggar@gmail.com

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Stanislav Malyshev at Jul 3, 2009 at 10:40 pm
    Hi!
    I think you could make this work for 5.3, if it used the old
    "zend_bool array_type_hint". A zend_bool is 8 bits, so that's plenty.
    It would be a little bit messy, but I'm fairly confident it could be
    made work.
    Unless the particular module would interpret everything that has
    non-zero array_type_hint as being typehinted to array, as it is now in
    5.3.0.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Hannes Magnusson at Jul 1, 2009 at 6:13 pm

    On Wed, Jul 1, 2009 at 18:59, Ilia Alshanetskywrote:
    The patch is available here: http://ia.gd/patch/type_hint_53.txt
    It is missing minor build fix for ext/reflection, see
    http://pastebin.com/f50db9aa1

    Other then that, I'm definitely +1 on this

    -Hannes
  • Guilherme Blanco at Jul 1, 2009 at 6:43 pm
    Although this sounds an extremely valid change, it breaks binary so
    I'm against on 5.3.

    Also, introducing type hints doesn't means that also core functions
    should follow it? Because currently '1' is converted to true.
    So in microtime for example... it should not support
    microtime('true'), but microtime(true) only.

    This is a change in zend_parse_parameters that automagically converts
    to correct type. That means more logic that if this is applied to
    userland, the same should be applied to internal functions.

    Just my 0.02.


    Cheers,

    On Wed, Jul 1, 2009 at 3:12 PM, Hannes
    Magnussonwrote:
    On Wed, Jul 1, 2009 at 18:59, Ilia Alshanetskywrote:
    The patch is available here: http://ia.gd/patch/type_hint_53.txt
    It is missing minor build fix for ext/reflection, see
    http://pastebin.com/f50db9aa1

    Other then that, I'm definitely +1 on this

    -Hannes

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


    --
    Guilherme Blanco - Web Developer
    CBC - Certified Bindows Consultant
    Cell Phone: +55 (16) 9215-8480
    MSN: guilhermeblanco@hotmail.com
    URL: http://blog.bisna.com
    São Paulo - SP/Brazil
  • Mark van der Velden at Jul 1, 2009 at 7:31 pm

    Ilia Alshanetsky wrote:
    There has been quite a bit of discussion on this list, IRC, developer
    meetings, etc... about introduction of type hinting to PHP.
    [..]

    My hope is that the latest changes will allow this to become a standard
    part of PHP. +1
    [..]
    - Mark
  • Geoffrey Sneddon at Jul 1, 2009 at 7:59 pm

    On 1 Jul 2009, at 18:59, Ilia Alshanetsky wrote:

    The main source of conflict appears to be that in some cases typical
    type hinting is just too strict for PHP's typeless nature (most
    people expect that "1" == 1, while int type hint would definitely
    reject string "1").
    To be fair, this is really my compliant, but:

    I think, for consistency, it should behaviour like
    zend_parse_parameters, hence not being overly strict, and should set
    the variable to it casted to the expected type. If it behaves
    differently to zend_parse_parameters then it'll be annoying that
    substr(), whose first parameter is a string, behaves differently to
    function foobar(string $what) when passed an int, for example.

    I'd expect:

    function foo(string $bar) {
    var_dump($bar);
    }

    foo(1234);

    To output:
    string(4) "1234"

    As this appears to be consistent with what internal functions that use
    zend_parse_parameters do. I don't want PHP to become any more
    inconsistent with itself than it already is.


    --
    Geoffrey Sneddon
    <http://gsnedders.com/>
  • Rodrigo Saboya at Jul 1, 2009 at 8:28 pm

    Ilia Alshanetsky wrote:
    There has been quite a bit of discussion on this list, IRC, developer
    meetings, etc... about introduction of type hinting to PHP. Most people
    appear to think that this would be a good idea, but there is a reason
    why it is not in PHP already. The main source of conflict appears to be
    that in some cases typical..
    This would be a great feature IMO. However, like others, I'm a bit
    concerned on how can consistency with internal functions be achieved.

    I don't think it would be that beneficial without method overloading by
    method signature. In fact, type hinting would be a step foward in that
    direction, and my head it makes sense that both features arrive
    togheter. I know nothing about php internals, method overloading by
    signature is something too hard to implement?

    And, while type hinting and method overloading are things I really miss
    in php when comparing to other languages (amongst other thinkgs) and I
    do think they would be fantastic, I think HEAD is more suited for thoses
    changes rather than 5.3 branch. (But I must confess I loved LSB and
    Closures in 5.3 :) )

    Regards
    Rodrigo Saboya
  • Kalle Sommer Nielsen at Jul 1, 2009 at 8:32 pm

    2009/7/1 Rodrigo Saboya <rodrigo.saboya@bolsademulher.com>:
    ...I think HEAD is more suited for thoses changes
    rather than 5.3 branch. (But I must confess I loved LSB and Closures in 5.3
    :) )
    Like said above, it can't (and wont go in 5.3) because it will break ABI



    --
    regrads,

    Kalle Sommer Nielsen
    kalle@php.net
  • Derick Rethans at Jul 1, 2009 at 8:53 pm

    On Wed, 1 Jul 2009, Ilia Alshanetsky wrote:


    I've taken a few hours this morning to port my 5.2 type hinting patch to 5.3.
    In recognition of a need for a more 'flexible' numeric type I've introduced
    (numeric) type hint that would allow bool/int/float data types as well as a
    string containing a numeric entity as identified by is_numeric_string(). For
    completion i've also added (scalar) data type that will allow any scalar data
    element.

    The patch is available here: http://ia.gd/patch/type_hint_53.txt
    +1

    regards,
    Derick
  • Peter Beverloo at Jul 2, 2009 at 7:31 am
    Hello,

    For what it's worth, a large +1 from me.

    One concern I do have, however, is that the addition of scalar type hints
    will put more attention to the lack of method overloading. Right now methods
    can accept multiple values due to the type-lessness, and while it will
    remain a possibility, code with type-hints usually is a lot clearner. To
    demonstrate:

    class Example {
    public function setValue (int $value) {}
    public function setValue (string $value) {}
    }

    While there are two obvious solutions for this (not using type-hinted
    parameters and using setIntValue/setStringValue) I think inclusion of a
    patch like this would be a good moment to overthink overloading like this.

    Peter


    "Ilia Alshanetsky" <ilia@prohost.org> wrote in message
    news:FC14FAFE-6785-4067-9B49-9FC14F159C52@prohost.org...
    I've taken a few hours this morning to port my 5.2 type hinting patch to
    5.3. In recognition of a need for a more 'flexible' numeric type I've
    introduced (numeric) type hint that would allow bool/int/float data types
    as well as a string containing a numeric entity as identified by
    is_numeric_string(). For completion i've also added (scalar) data type
    that will allow any scalar data element.

    The patch is available here: http://ia.gd/patch/type_hint_53.txt

    It should be noted that this patch is fully compatible with opcode caches
    and and requires no changes on the part of an opcode cache such as APC to
    work.

    My hope is that the latest changes will allow this to become a standard
    part of PHP.

    Ilia Alshanetsky

    P.S.

    It should be noted that this is not the first idea for type hints, that
    credit goes to Hannes Magnusson who had posted a similar patch on the
    internals list back in 2006. Also, back in 2008 Felipe Pena wrote a type
    hinting patch for PHP that is available on wiki.php.net.
  • Ionut G. Stan at Jul 2, 2009 at 9:26 am
    Hi,

    I'm a userland developer with limited C skills, and while I don't yet
    have an
    opinion on the whole type enforcing issue, aside from a fear of
    libraries abusing
    it, I'd like to propose a little change in the patch.

    Is it possible that instead of an E_RECOVERABLE_ERROR, an Exception to
    be thrown? I don't know whether InvalidArgumentException satisfies the
    semantics,
    but it's a step in that direction.
    On 7/1/2009 19:59, Ilia Alshanetsky wrote:
    There has been quite a bit of discussion on this list, IRC, developer
    meetings, etc... about introduction of type hinting to PHP. Most
    people appear to think that this would be a good idea, but there is a
    reason why it is not in PHP already. The main source of conflict
    appears to be that in some cases typical type hinting is just too
    strict for PHP's typeless nature (most people expect that "1" == 1,
    while int type hint would definitely reject string "1"). Personally,
    I disagree with that opinion, but I can understand people who raise
    that issue. At work we've been using PHP 5.2 with type hinting for
    nearly 2 years now with great success, it makes code much easier to
    read and understand and the security benefit of type hinting is not to
    be under valued. In many cases type hinting can present a last line of
    defense against unexpected input for numeric fields, which are
    typically abused to do SQL injection.

    I've taken a few hours this morning to port my 5.2 type hinting patch
    to 5.3. In recognition of a need for a more 'flexible' numeric type
    I've introduced (numeric) type hint that would allow bool/int/float
    data types as well as a string containing a numeric entity as
    identified by is_numeric_string(). For completion i've also added
    (scalar) data type that will allow any scalar data element.

    The patch is available here: http://ia.gd/patch/type_hint_53.txt

    It should be noted that this patch is fully compatible with opcode
    caches and and requires no changes on the part of an opcode cache such
    as APC to work.

    My hope is that the latest changes will allow this to become a
    standard part of PHP.

    Ilia Alshanetsky

    P.S.

    It should be noted that this is not the first idea for type hints,
    that credit goes to Hannes Magnusson who had posted a similar patch on
    the internals list back in 2006. Also, back in 2008 Felipe Pena wrote
    a type hinting patch for PHP that is available on wiki.php.net.
    --
    Ionut G. Stan
    I'm under construction | http://igstan.blogspot.com/
  • Kalle Sommer Nielsen at Jul 2, 2009 at 10:42 am
    Hi

    2009/7/2 Ionut G. Stan <ionut.g.stan@gmail.com>:
    Is it possible that instead of an E_RECOVERABLE_ERROR, an Exception to
    be thrown? I don't know whether InvalidArgumentException satisfies the
    semantics,
    but it's a step in that direction.
    I don't think we should start changing the standard way of the engine
    to error out, having a custom error that checks for
    E_RECOVERABLE_ERROR can be made to throw an InvalidArgumentException
    within few lines of code/parsing.


    --
    regrads,

    Kalle Sommer Nielsen
    kalle@php.net
  • Hannes Magnusson at Jul 2, 2009 at 10:56 am

    On Thu, Jul 2, 2009 at 11:24, Ionut G. Stanwrote:
    Hi,

    I'm a userland developer with limited C skills, and while I don't yet have
    an
    opinion on the whole type enforcing issue, aside from a fear of libraries
    abusing
    it, I'd like to propose a little change in the patch.

    Is it possible that instead of an E_RECOVERABLE_ERROR, an Exception to
    be thrown? I don't know whether InvalidArgumentException satisfies the
    semantics,
    but it's a step in that direction.
    <?php
    function throw_exception($errno, $errmsg) {
    if (strpos($errmsg, "Argument ") === 0) {
    throw new InvalidArgumentException($errmsg, $errno);
    }
    return false;
    }
    set_error_handler("throw_exception", E_RECOVERABLE_ERROR);

    function foo(array $arr) {}
    foo("string");


    Here you go.

    -Hannes

Related Discussions

People

Translate

site design / logo © 2022 Grokbase