# RFC: Type hinting revisited for PHP 5.3 - Thread: https://externals.io/message/44573 - Original archive: https://news-web.php.net/php.internals/44573 - Started by Ilia Alshanetsky on 2009-07-01T16:59:59+00:00 - Messages: 59 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/44573.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #44573 — Ilia Alshanetsky — 2009-07-01T16:59:59+00:00 URL: https://externals.io/message/44573#44573 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. --- ## #44574 — Gwynne Raskind — 2009-07-01T17:09:18+00:00 URL: https://externals.io/message/44573#44574 · In reply to: #44573 > 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 --- ## #44578 — Graham Kelly — 2009-07-01T17:13:43+00:00 URL: https://externals.io/message/44573#44578 · In reply to: #44574 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: > > > > […] > [snip] > > > […] > > +1 (+1000, actually :) > > -- Gwynne --- ## #44575 — Alain Williams — 2009-07-01T17:15:33+00:00 URL: https://externals.io/message/44573#44575 · In reply to: #44573 > 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 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/ --- ## #44577 — Tom Boutell — 2009-07-01T17:22:09+00:00 URL: https://externals.io/message/44573#44577 · In reply to: #44575 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? > > > […] > > 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 > > -- > > > > -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com --- ## #44579 — Graham Kelly — 2009-07-01T17:22:24+00:00 URL: https://externals.io/message/44573#44579 · In reply to: #44575 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. > > > […] > > 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 wrote: > Ilia Alshanetsky schrieb: > > […] > >  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 P'unk Avenue 215 755 1330 punkave.com window.punkave.com --- ## #44581 — Paul Biggar — 2009-07-01T17:23:55+00:00 URL: https://externals.io/message/44573#44581 · In reply to: #44573 Hi Ilia, This is great. > 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. > -- > > > > -- Paul Biggar paul.biggar@gmail.com --- ## #44588 — Ilia Alshanetsky — 2009-07-01T17:40:42+00:00 URL: https://externals.io/message/44573#44588 · In reply to: #44577 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. > 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 > wrote: > > […] > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com --- ## #44589 — Ilia Alshanetsky — 2009-07-01T17:45:01+00:00 URL: https://externals.io/message/44573#44589 · In reply to: #44581 If you use int type hit "1" will be rejected, but if use numeric type hint it will be accepted. Ilia Alshanetsky > Hi Ilia, > > This is great. > > On Wed, Jul 1, 2009 at 5:59 PM, Ilia Alshanetsky > wrote: > > […] > > I think this will go a long way to addressing people's concerns when > this came up previously. > > > > […] > > 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 > > > > […] > > > > -- > Paul Biggar > paul.biggar@gmail.com --- ## #44582 — Matt Wilson — 2009-07-01T18:05:05+00:00 URL: https://externals.io/message/44573#44582 · In reply to: #44581 +1000 * infinity plus one > Hi Ilia, > > This is great. > > On Wed, Jul 1, 2009 at 5:59 PM, Ilia Alshanetsky > wrote: > > […] > > I think this will go a long way to addressing people's concerns when > this came up previously. > > > > […] > > 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 > > > > […] > > > > -- > Paul Biggar > paul.biggar@gmail.com --- ## #44583 — Stanislav Malyshev — 2009-07-01T18:07:04+00:00 URL: https://externals.io/message/44573#44583 · In reply to: #44573 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 --- ## #44584 — Hannes Magnusson — 2009-07-01T18:12:54+00:00 URL: https://externals.io/message/44573#44584 · In reply to: #44573 > 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 --- ## #44587 — Ilia Alshanetsky — 2009-07-01T18:18:03+00:00 URL: https://externals.io/message/44573#44587 · In reply to: #44583 As far as your point goes, numeric hint addresses it. Ilia Alshanetsky CIO/CSO Centah Inc. > Hi! > > > […] > > 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 --- ## #44591 — Guilherme Blanco — 2009-07-01T18:42:56+00:00 URL: https://externals.io/message/44573#44591 · In reply to: #44584 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 Magnusson wrote: > > > […] > > 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 - 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 --- ## #44592 — Stanislav Malyshev — 2009-07-01T18:44:11+00:00 URL: https://externals.io/message/44573#44592 · In reply to: #44587 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 --- ## #44593 — Paul Biggar — 2009-07-01T18:52:41+00:00 URL: https://externals.io/message/44573#44593 · In reply to: #44592 > Hi! > > > […] > > 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 --- ## #44595 — Stanislav Malyshev — 2009-07-01T19:04:16+00:00 URL: https://externals.io/message/44573#44595 · In reply to: #44593 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 --- ## #44596 — Paul Biggar — 2009-07-01T19:11:43+00:00 URL: https://externals.io/message/44573#44596 · In reply to: #44595 > > […] > > 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). > > […] > > 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 --- ## #44598 — Mark van der Velden — 2009-07-01T19:30:57+00:00 URL: https://externals.io/message/44573#44598 · In reply to: #44573 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 --- ## #44601 — Ilia Alshanetsky — 2009-07-01T19:41:53+00:00 URL: https://externals.io/message/44573#44601 · In reply to: #44592 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 > Hi! > > > […] > > 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 --- ## #44600 — Geoffrey Sneddon — 2009-07-01T19:59:13+00:00 URL: https://externals.io/message/44573#44600 · In reply to: #44573 > 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 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 --- ## #44603 — Stanislav Malyshev — 2009-07-01T20:29:37+00:00 URL: https://externals.io/message/44573#44603 · In reply to: #44601 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 --- Next page: https://externals.io/message/44573.md?page=2