Re: [PHP-DEV] Re: Throwing E_DEPRECATED on startup
2009/6/30 Hannes Magnusson hannes.magnus...@gmail.com: Now that 5.3.0 is out, are you looking into fixing run-tests.php or all tests? run-tests.php seems most reasonable to fix, and then those tests that fail (aka. those who havnt been updated to catch these warnings). Like I warned about; if you enable any of these features in your php.ini and then run the test suite.. there are only a handful of tests that actually pass. I can see us passing -n parameter to the binary when executing a test, as most tests rely on the default builtin values in php. -- regrads, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Throwing E_DEPRECATED on startup
On Wed, Jul 1, 2009 at 08:05, Kalle Sommer Nielsenka...@php.net wrote: 2009/6/30 Hannes Magnusson hannes.magnus...@gmail.com: Like I warned about; if you enable any of these features in your php.ini and then run the test suite.. there are only a handful of tests that actually pass. I can see us passing -n parameter to the binary when executing a test, as most tests rely on the default builtin values in php. That defeats the point of the tests. They need to be tested under various configurations. For those tests that require special INI settings we have the --INI-- section to make sure those are set the way the test requires it. Everything else should work under other configurations. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Throwing E_DEPRECATED on startup
Uwe Schindler wrote: I had the same this morning when I compiled PHP on my solaris machine. The php.ini from my system-wide lib folder was used for the tests. In my case it claimed about the deprecated *_long_arrays setting (or something like that). Almost no test worked until I edited my global php.ini. Tests should use a local php.ini in the build directory. Well, actually they do use local ini. It's just sanitized version of your global one. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: php 5.3 on windows does not work with go-pear.phar
Christian Weiske wrote: Hi, Several users reported that the windows package of php 5.3 does not work with the phar: - http://pastebin.com/d79a424b3 - http://pastebin.com/d49c8cc02 phar C:\Users\Sebastian Bergmann\php\PEAR\go-pear.phar does not have a signature Warning: require_once(phar://go-pear.phar/index.php): failed to open stream: phar error: invalid url or non-existent phar phar://go-pear.phar/index.php in C:\ Users\Sebastian Bergmann\php\PEAR\go-pear.phar on line 1236 Sorry about this problem, the fix is simple, is not a bug in PHP or in phar, and is just a developer oversight. First, add -drequire_hash=0 to go-pear.bat as a temporary fix for those who already have PHP 5.3.0, and the permanent fix is to re-generate the go-pear.phar on a machine with ext/phar installed. I am not sure how this slipped through, perhaps I have the require_hash=0 in my php.ini on windows and forgot about it (will have to check) Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: php 5.3 on windows does not work with go-pear.phar
Greg Beaver schrieb: First, add -drequire_hash=0 to go-pear.bat as a temporary fix for those who already have PHP 5.3.0, and the permanent fix is to re-generate the go-pear.phar on a machine with ext/phar installed. That should have been -d phar.require_hash=0, I guess. -- Sebastian BergmannCo-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
Re: [PHP-DEV] Re: php 5.3 on windows does not work with go-pear.phar
Sebastian Bergmann wrote: Greg Beaver schrieb: First, add -drequire_hash=0 to go-pear.bat as a temporary fix for those who already have PHP 5.3.0, and the permanent fix is to re-generate the go-pear.phar on a machine with ext/phar installed. That should have been -d phar.require_hash=0, I guess. Hi, This is correct, sorry again. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [5.3] Howto build mysql, mysqli and pdo_mysql with libmysql on Windows
Hi all, anybody knows, how to build especially pdo_mysql with libmysql on Windows (I've managed to build mysql and mysqli with a change in the config.w32 files)? My configure string is something like: | cscript /nologo configure.js --disable-all \ | ... \ | --without-mysqlnd \ | --with-mysql=shared \ | --with-mysqli=shared \ | --with-pdo-mysql=shared The build stops with errors in mysql_statement.c, like: | mysql_statement.c(52) : error C2039: 'stmt' mysql and mysqli are working fine. All three extensions are working and build with mysqlnd. However, how can I connect to a named pipe with mysqlnd. All my scripts are using the usual hostname = .. But that's not working with a mysqlnd build. Another question: With a default PHP 5.3 installation, I just changed: | log_errors = On | error_log = php_errors.log (date.timezone is still not defined.) Now, if I do a php -i in the shell I have this repeating message in a loop (and a lot of entries in the defined log): Warning: Unknown: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set () function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Paris' for '2.0/DST' instead in Unknown on line 0 If I do a phpinfo with the Apache module, my Apache hangs up. I have the same error messages (in a loop), If I just do a php -r 'errror;' in the shell. BTW: Why is this a warning, if I don't set the timezone in php.ini? -- The reason for the timezone applet in my Windows configuration is, to setup the timezone for all applications at one place. Well, it's nice that I can change my server timezone for one app (like PHP) in the config file. But this should only be necessary if I'm knowing what I'm doing and in really rare cases. (e.g. MySQL is still using my Win server timezone for time calculations) Regards, Carsten mysqli_warning.c rc /n /fo .\Release_TS\php_mysqli.dll.res /d FILE_DESCRIPTION=\MySQLi\ /d FILE_NAME=\php_mysqli.dll\ /d URL=\http://www.php.net\; /d INTERNAL _NAME=\MYSQLI extension\ /d THANKS_GUYS=\Thanks to Zak Greant, Georg Richt er, Andrey Hristov, Ulf Wendel\ win32\build\template.rc Bibliothek .\Release_TS\php_mysqli.lib und Objekt .\Release_TS\php_mysqli.exp wird erstellt EXT mysqli build complete Bibliothek .\Release_TS\php_pdo.lib und Objekt .\Release_TS\php_pdo.exp wird erstellt EXT pdo build complete Bibliothek .\Release_TS\php_pdo_mssql.lib und Objekt .\Release_TS\php_pdo_mss ql.exp wird erstellt EXT pdo_mssql build complete Bibliothek .\Release_TS\php_pdo_firebird.lib und Objekt .\Release_TS\php_pdo_ firebird.exp wird erstellt EXT pdo_firebird build complete mysql_driver.c mysql_statement.c ext\pdo_mysql\mysql_statement.c(40) : warning C4005: 'pdo_mysql_stmt_execute_pre pared' : Makro-Neudefinition ext\pdo_mysql\mysql_statement.c(0) : Siehe vorherige Definition von 'pdo _mysql_stmt_execute_prepared' ext\pdo_mysql\mysql_statement.c(52) : error C2039: 'stmt' : Ist kein Element von 'pdo_mysql_stmt' ext\pdo_mysql\php_pdo_mysql_int.h(114) : Siehe Deklaration von 'pdo_mysq l_stmt' ext\pdo_mysql\mysql_statement.c(70) : error C2039: 'params' : Ist kein Element v on 'pdo_mysql_stmt' ext\pdo_mysql\php_pdo_mysql_int.h(114) : Siehe Deklaration von 'pdo_mysq l_stmt' ext\pdo_mysql\mysql_statement.c(71) : error C2039: 'params' : Ist kein Element v on 'pdo_mysql_stmt' ext\pdo_mysql\php_pdo_mysql_int.h(114) : Siehe Deklaration von 'pdo_mysq l_stmt' ext\pdo_mysql\mysql_statement.c(71) : error C2198: '_efree' : Nicht genuegend Pa rameter uebergeben ext\pdo_mysql\mysql_statement.c(73) : error C2039: 'in_null' : Ist kein Element von 'pdo_mysql_stmt' ext\pdo_mysql\php_pdo_mysql_int.h(114) : Siehe Deklaration von 'pdo_mysq l_stmt' ext\pdo_mysql\mysql_statement.c(74) : error C2039: 'in_null' : Ist kein Element von 'pdo_mysql_stmt' ext\pdo_mysql\php_pdo_mysql_int.h(114) : Siehe Deklaration von 'pdo_mysq l_stmt' ext\pdo_mysql\mysql_statement.c(74) : error C2198: '_efree' : Nicht genuegend Pa rameter uebergeben ext\pdo_mysql\mysql_statement.c(76) : error C2039: 'in_length' : Ist kein Elemen t von 'pdo_mysql_stmt' ext\pdo_mysql\php_pdo_mysql_int.h(114) : Siehe Deklaration von 'pdo_mysq l_stmt' ext\pdo_mysql\mysql_statement.c(77) : error C2039: 'in_length' : Ist kein Elemen t von 'pdo_mysql_stmt' ext\pdo_mysql\php_pdo_mysql_int.h(114) : Siehe Deklaration von 'pdo_mysq l_stmt' ext\pdo_mysql\mysql_statement.c(77) : error C2198: '_efree' : Nicht genuegend Pa rameter uebergeben ext\pdo_mysql\mysql_statement.c(127) : error C2039: 'stmt' : Ist kein Element vo n 'pdo_mysql_stmt' ext\pdo_mysql\php_pdo_mysql_int.h(114) : Siehe Deklaration
[PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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 BergmannCo-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
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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 Williamsa...@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
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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 gwy...@darkrainfall.orgwrote: 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
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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 a...@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 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
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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 Bergmanns...@sebastian-bergmann.de wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi Ilia,
This is great.
On Wed, Jul 1, 2009 at 5:59 PM, Ilia Alshanetskyi...@prohost.org 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.
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.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
+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 Alshanetskyi...@prohost.org
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.
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.big...@gmail.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
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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 s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, Jul 1, 2009 at 18:59, Ilia Alshanetskyi...@prohost.org wrote: 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
[PHP-DEV] CGI and FastCGI SAPI
Hi, I'm trying to understand how difficult it is to create a new SAPI, so I started to poke my nose inside the cgi SAPI source code. I saw that cgi_main.c implements both the CGI and the FastCGI protocols and I kinda got lost inside all those if-else lines (I tried to take out the FastCGI code and failed miserably). I'm wondering if it's not better to have 2 different SAPIs, one for CGI and for FastCGI. Advantages of this split would be: - the source code will be more readable without all those if-else statements - we would have 2 executables that do 2 different jobs, unlike now where php-cgi does both; each executable could then be further optimized for the exact job they are performing Disadvantages I see: - maintaning 2 SAPI implementaion would require more work (since CGI and FastCGI both share most of the SAPI code, any change would have to be replicated twice) - break backward compatibility (where php-cgi handles both CGI and FastCGI) Thank you for your time, Gelu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and FastCGI SAPI
I think it would be a good idea to also include PHP-FPM in your investigation. On Wed, Jul 1, 2009 at 11:02 AM, Gelu Kelundengelu.k...@gmail.com wrote: Hi, I'm trying to understand how difficult it is to create a new SAPI, so I started to poke my nose inside the cgi SAPI source code. I saw that cgi_main.c implements both the CGI and the FastCGI protocols and I kinda got lost inside all those if-else lines (I tried to take out the FastCGI code and failed miserably). I'm wondering if it's not better to have 2 different SAPIs, one for CGI and for FastCGI. Advantages of this split would be: - the source code will be more readable without all those if-else statements - we would have 2 executables that do 2 different jobs, unlike now where php-cgi does both; each executable could then be further optimized for the exact job they are performing Disadvantages I see: - maintaning 2 SAPI implementaion would require more work (since CGI and FastCGI both share most of the SAPI code, any change would have to be replicated twice) - break backward compatibility (where php-cgi handles both CGI and FastCGI) Thank you for your time, Gelu -- 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
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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 s...@zend.com 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 s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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 t...@punkave.com 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 Williamsa...@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
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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 paul.big...@gmail.com wrote:
Hi Ilia,
This is great.
On Wed, Jul 1, 2009 at 5:59 PM, Ilia Alshanetskyi...@prohost.org
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.
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.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and FastCGI SAPI
I think that the official FastCGI implementation will eventually evolve into something like PHP-FPM, if not even more. What I'm saying is that code that handles daemonization (uid/gid/chroot/log), workers mgmt (spawing/safe-shutdown), daemon config file (not php.ini or php-cgi.ini) should not be present in the pure CGI SAPI implementation, but in a different FastCGI-only SAPI. Gelu Michael Shadle mike...@gmail.com wrote in message news:bd9320b3090707q4fc2c2c3hbffbf289679e6...@mail.gmail.com... I think it would be a good idea to also include PHP-FPM in your investigation. On Wed, Jul 1, 2009 at 11:02 AM, Gelu Kelundengelu.k...@gmail.com wrote: Hi, I'm trying to understand how difficult it is to create a new SAPI, so I started to poke my nose inside the cgi SAPI source code. I saw that cgi_main.c implements both the CGI and the FastCGI protocols and I kinda got lost inside all those if-else lines (I tried to take out the FastCGI code and failed miserably). I'm wondering if it's not better to have 2 different SAPIs, one for CGI and for FastCGI. Advantages of this split would be: - the source code will be more readable without all those if-else statements - we would have 2 executables that do 2 different jobs, unlike now where php-cgi does both; each executable could then be further optimized for the exact job they are performing Disadvantages I see: - maintaning 2 SAPI implementaion would require more work (since CGI and FastCGI both share most of the SAPI code, any change would have to be replicated twice) - break backward compatibility (where php-cgi handles both CGI and FastCGI) Thank you for your time, Gelu -- 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
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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
Magnussonhannes.magnus...@gmail.com wrote:
On Wed, Jul 1, 2009 at 18:59, Ilia Alshanetskyi...@prohost.org wrote:
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: guilhermebla...@hotmail.com
URL: http://blog.bisna.com
São Paulo - SP/Brazil
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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 s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, Jul 1, 2009 at 7:44 PM, Stanislav Malyshevs...@zend.com 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! :). 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.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and FastCGI SAPI
On Jul 1, 2009, at 2:37 PM, Gelu Kelunden wrote: I think that the official FastCGI implementation will eventually evolve into something like PHP-FPM, if not even more. What I'm saying is that code that handles daemonization (uid/gid/ chroot/log), workers mgmt (spawing/safe-shutdown), daemon config file (not php.ini or php-cgi.ini) should not be present in the pure CGI SAPI implementation, but in a different FastCGI-only SAPI. This seems to me as if it would be a step backwards. For a long time CGI and FastCGI were highly separate setups; you had to use configure flags to enable FastCGI, and so forth. In 5.3 they were unified completely: you can't have one without the other anymore. Why would you need to? -- Gwynne Michael Shadle mike...@gmail.com wrote in message news:bd9320b3090707q4fc2c2c3hbffbf289679e6...@mail.gmail.com ... I think it would be a good idea to also include PHP-FPM in your investigation. On Wed, Jul 1, 2009 at 11:02 AM, Gelu Kelundengelu.k...@gmail.com wrote: Hi, I'm trying to understand how difficult it is to create a new SAPI, so I started to poke my nose inside the cgi SAPI source code. I saw that cgi_main.c implements both the CGI and the FastCGI protocols and I kinda got lost inside all those if-else lines (I tried to take out the FastCGI code and failed miserably). I'm wondering if it's not better to have 2 different SAPIs, one for CGI and for FastCGI. Advantages of this split would be: - the source code will be more readable without all those if-else statements - we would have 2 executables that do 2 different jobs, unlike now where php-cgi does both; each executable could then be further optimized for the exact job they are performing Disadvantages I see: - maintaning 2 SAPI implementaion would require more work (since CGI and FastCGI both share most of the SAPI code, any change would have to be replicated twice) - break backward compatibility (where php-cgi handles both CGI and FastCGI) Thank you for your time, Gelu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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 s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, Jul 1, 2009 at 8:04 PM, Stanislav Malyshevs...@zend.com wrote: 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.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and FastCGI SAPI
Actually I see it a step forward. In the beginning, the cgi SAPI implemented only the CGI protocol. Support for FastCGI was added gradually on top of the pure CGI implementation. In order to test this non-stable code, one would have to use --enable-fastcgi. Now FastCGI code is stable enough (and also FastCGI got more widespread and now is the way to do it) to be built by default. And, as of 5.3.0, you cannot build a CGI-only executable anymore. New features will definately be added to the FastCGI implementation and I this it might be good to make the FastCGI SAPI stand-alone and not keep arround the CGI-only legacy code. Gelu Gwynne Raskind gwy...@darkrainfall.org wrote in message news:96158496-0c9a-4568-9a74-2d606730d...@darkrainfall.org... On Jul 1, 2009, at 2:37 PM, Gelu Kelunden wrote: I think that the official FastCGI implementation will eventually evolve into something like PHP-FPM, if not even more. What I'm saying is that code that handles daemonization (uid/gid/ chroot/log), workers mgmt (spawing/safe-shutdown), daemon config file (not php.ini or php-cgi.ini) should not be present in the pure CGI SAPI implementation, but in a different FastCGI-only SAPI. This seems to me as if it would be a step backwards. For a long time CGI and FastCGI were highly separate setups; you had to use configure flags to enable FastCGI, and so forth. In 5.3 they were unified completely: you can't have one without the other anymore. Why would you need to? -- Gwynne Michael Shadle mike...@gmail.com wrote in message news:bd9320b3090707q4fc2c2c3hbffbf289679e6...@mail.gmail.com ... I think it would be a good idea to also include PHP-FPM in your investigation. On Wed, Jul 1, 2009 at 11:02 AM, Gelu Kelundengelu.k...@gmail.com wrote: Hi, I'm trying to understand how difficult it is to create a new SAPI, so I started to poke my nose inside the cgi SAPI source code. I saw that cgi_main.c implements both the CGI and the FastCGI protocols and I kinda got lost inside all those if-else lines (I tried to take out the FastCGI code and failed miserably). I'm wondering if it's not better to have 2 different SAPIs, one for CGI and for FastCGI. Advantages of this split would be: - the source code will be more readable without all those if-else statements - we would have 2 executables that do 2 different jobs, unlike now where php-cgi does both; each executable could then be further optimized for the exact job they are performing Disadvantages I see: - maintaning 2 SAPI implementaion would require more work (since CGI and FastCGI both share most of the SAPI code, any change would have to be replicated twice) - break backward compatibility (where php-cgi handles both CGI and FastCGI) Thank you for your time, Gelu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and FastCGI SAPI
Any way you guys decide to do it, I think taking learnings and/or code directly from PHP-FPM could be key to base this off of. One suggestion might be improving the hooks into PHP so that the process management component can be done separately. This would allow for distributions to send it as a separate package and the configuration portion of the FPM can be done in userland as opposed to PHP internally. PHP just needs the hooks into it. I've already got the following folks in related discussions, which I believe are the key players in who can help make the decisions on what to adopt, etc. Stanislav Malyshev Dmitry Stogov Andrei Nigmatulin Andi Gutmans Just waiting to have the rubber hit the road and determine the next steps. Another benefit to adding only the required hooks into PHP core and keeping FPM in PECL or something else is so that the adaptive process spawning, angel process creation (which I think would be required for adaptive monitoring) and other features that never got finished or I'd like to see implemented could be implemented independent of PHP development, and PHP core would only need to be patched if something required a new hook that a PECL/external module or controller could not handle. I'd rather see it done in that fashion probably, as waiting for the next even minor version of PHP for certain FPM features might take a while, and I have a wishlist which I'd like to turn into a roadmap for the FPM functionality, and PHP has a large codebase that can't move as fast as I'd like for FPM if it was just merged directly in. On Wed, Jul 1, 2009 at 12:26 PM, Gelu Kelundengelu.k...@gmail.com wrote: Actually I see it a step forward. In the beginning, the cgi SAPI implemented only the CGI protocol. Support for FastCGI was added gradually on top of the pure CGI implementation. In order to test this non-stable code, one would have to use --enable-fastcgi. Now FastCGI code is stable enough (and also FastCGI got more widespread and now is the way to do it) to be built by default. And, as of 5.3.0, you cannot build a CGI-only executable anymore. New features will definately be added to the FastCGI implementation and I this it might be good to make the FastCGI SAPI stand-alone and not keep arround the CGI-only legacy code. Gelu Gwynne Raskind gwy...@darkrainfall.org wrote in message news:96158496-0c9a-4568-9a74-2d606730d...@darkrainfall.org... On Jul 1, 2009, at 2:37 PM, Gelu Kelunden wrote: I think that the official FastCGI implementation will eventually evolve into something like PHP-FPM, if not even more. What I'm saying is that code that handles daemonization (uid/gid/ chroot/log), workers mgmt (spawing/safe-shutdown), daemon config file (not php.ini or php-cgi.ini) should not be present in the pure CGI SAPI implementation, but in a different FastCGI-only SAPI. This seems to me as if it would be a step backwards. For a long time CGI and FastCGI were highly separate setups; you had to use configure flags to enable FastCGI, and so forth. In 5.3 they were unified completely: you can't have one without the other anymore. Why would you need to? -- Gwynne Michael Shadle mike...@gmail.com wrote in message news:bd9320b3090707q4fc2c2c3hbffbf289679e6...@mail.gmail.com ... I think it would be a good idea to also include PHP-FPM in your investigation. On Wed, Jul 1, 2009 at 11:02 AM, Gelu Kelundengelu.k...@gmail.com wrote: Hi, I'm trying to understand how difficult it is to create a new SAPI, so I started to poke my nose inside the cgi SAPI source code. I saw that cgi_main.c implements both the CGI and the FastCGI protocols and I kinda got lost inside all those if-else lines (I tried to take out the FastCGI code and failed miserably). I'm wondering if it's not better to have 2 different SAPIs, one for CGI and for FastCGI. Advantages of this split would be: - the source code will be more readable without all those if-else statements - we would have 2 executables that do 2 different jobs, unlike now where php-cgi does both; each executable could then be further optimized for the exact job they are performing Disadvantages I see: - maintaning 2 SAPI implementaion would require more work (since CGI and FastCGI both share most of the SAPI code, any change would have to be replicated twice) - break backward compatibility (where php-cgi handles both CGI and FastCGI) Thank you for your time, Gelu -- 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
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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 s...@zend.com 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 s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC: Type hinting revisited for PHP 5.3
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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 s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: Type hinting revisited for PHP 5.3
2009/7/1 Rodrigo Saboya rodrigo.sab...@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 ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, Jul 1, 2009 at 22:29, Stanislav Malyshevs...@zend.com wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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 s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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 -- http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org twitter: @derickr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, Jul 1, 2009 at 22:50, Stanislav Malyshevs...@zend.com wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, Jul 1, 2009 at 10:02 PM, Hannes
Magnussonhannes.magnus...@gmail.com wrote:
On Wed, Jul 1, 2009 at 22:50, Stanislav Malyshevs...@zend.com wrote:
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.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, Jul 1, 2009 at 23:07, Paul Biggarpaul.big...@gmail.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, Jul 1, 2009 at 10:23 PM, Hannes Magnussonhannes.magnus...@gmail.com wrote: On Wed, Jul 1, 2009 at 23:07, Paul Biggarpaul.big...@gmail.com wrote: 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.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, Jul 1, 2009 at 23:36, Paul Biggarpaul.big...@gmail.com wrote:
On Wed, Jul 1, 2009 at 10:23 PM, Hannes
Magnussonhannes.magnus...@gmail.com wrote:
On Wed, Jul 1, 2009 at 23:07, Paul Biggarpaul.big...@gmail.com wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
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 s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, Jul 1, 2009 at 10:53 PM, Hannes
Magnussonhannes.magnus...@gmail.com wrote:
On Wed, Jul 1, 2009 at 23:36, Paul Biggarpaul.big...@gmail.com wrote:
On Wed, Jul 1, 2009 at 10:23 PM, Hannes
Magnussonhannes.magnus...@gmail.com wrote:
On Wed, Jul 1, 2009 at 23:07, Paul Biggarpaul.big...@gmail.com wrote:
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.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: Boxing and Unboxing
Greetings All, Intro = The discussion over type hinting seems to be getting divided between those who really like it (most likely the ones who write strongly typed programs anyway) and those who don't want to add yet another kind of type system to PHP. I have been thinking about it and wondered why we don't borrow a concept from C# with a PHP twist of course. The basic idea of boxing in C# is that a value type is implicitly converted to an object type. Unboxing is done explicitly to convert the object back to a value type. Idea I figure instead of adding scalar type hints, we could reuse the object type hints to do implicit boxing of variables. Either (but not both) a new magic method (``__box`` for example) or a new interface (``Boxable`` for example) would need to be added to PHP. The method would accept the scalar value and set its internal representation (similar to ``__wakeup``). The method could either (but not both) return false or throw an exception (``BoxingException`` for example). It is my belief that PHP would need to include as many object versions of scalar types as possible. The boxing functionality could be added to the SPL Types [1]_ to provide for standard representations of the scalar types. However the power to box variables would also be available in userland classes. The unboxing of variables would need to occur on an explicit cast or on a call to an internal function. The unboxing could be implemented as the RFC for class casting to scalar [2]_. It already discusses some examples for a new magic method or interface. I propose some more to relate to the unboxing concept (``__unbox`` for a magic method, and ``Unboxable`` for an interface). Benefits The benefits to boxing and unboxing include: - Only minor modifications required to the current type-hinting implementation (I am only assuming this part). - The boxing and unboxing ability can be used in userland classes to accomplish cool things. - Get SplTypes and scalar casting in PHP core. - Probably more that I can't think of off the top of my head. Patch = I have very limited C skills, so no patch exists. .. [1] `SPL Types http://.php.net/manual/en/book.spl-types.php`_ .. [2] `RFC: Class casting to scalar http://wiki.php.net/rfc/class_casting_to_scalar`_ Thanks, -- Joshua Thompson Mechanical Engineer/Software Developer http://www.schmalls.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CLI benchmark ready for testing
Hi there! The php CLI benchmark is now pretty much ready for some testing. I'd like any type of feature feedback and bug reports are appreciated. There is a brief documentation available at the scratchpad, http://wiki.php.net/doc/scratchpad/benchmark . It describes the main features and how it can be used. Keep in mind that the cachegrind tool takes very long time to execute, so I suggest using only --path microtests if it is for testing only, since it will be way shorter in that case. The location of the cvs is http://cvs.php.net/viewvc.cgi/php-benchmarks/ . Comments are appreciated, good or/and bad :) Best regards Alexander
[PHP-DEV] Socket Timeout Documentation
All: Perhaps we should clarify the socket tuneables such as: ; Default timeout for socket based streams (seconds) default_socket_timeout = 60 These are slightly ambiguous. e.g., we should clarify connect() timeouts v.s. idle timeouts. There are at least a dozen tickets open related to timeout behavior and a lot of the confusion results of ambiguity in the variable naming convention and documentation. ~BAS -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Flexible type hinting
Hi folks,
Thanks to Ilia for getting to ball rolling on scalar type hinting.
It seems there are 3 camps:
- (C) the type checking camp: when I say 'int' I mean 'int'. This
is what Ilia's patch does.
- (H) the type hinting crowd: 'int' is a hint to the user that an
int is expected. This gels well with PHP's weakly typed scalars. I
think few people are in this crowd, but a lot of the (S) crowd are
mistakenly thought to be.
- (S) the sensible middle: 'int' means an integer of course. The
manual is written somewhere between (S) and (H).
I believe I have a solution that caters to each crowd, without being
too complicated.
There are advantages and disadvantage to all of these:
- The main disadvantage of each system is that it doesnt provide what
the other systems allow. Strong is too strong for many. Weak is too
weak for most.
- Ilia had a very good point against (H), which is that many
functions return NULL or FALSE, and there are lots of errors when
these are automatically (and silently) converted to 0 or . (H) will
not catch anything.
- A strong argument against (C) is that this currently has no
parallel with how scalars are handled in PHP currently.
- A (I think weak) argument for (C) is that this is how object type
hinting works
- An argument for (H)/(S) is that the manual has been written in this
style, using this syntax.
- A good argument against (C) is that it cannot be used to hint PHP's
builtin functions.
- The (C) crowd suggested numeric and scalar to the (H) crowd, but I
dont think they were impressed.
- I dont think there is a strong case for a strongly typed bool.
Here is the solution:
By default, use (S). The semantics of (S) are roughly provided in a
table at the bottom. The idea is that for ints, we take 5, and 5,
and fail on str, FALSE, resource, etc.
Allow a very easy way to get (C) and (H) using '+' and '-'. +int
means fail on anything but an int. This is (C). -int means I expect
an int, but I'll take whatever you give me, and cast it to an int.
This is (H). (H) is for those times where neither (C) nor (S) are
suitable, which occurs in the standard library a lot. I hope that it
wouldnt be used much otherwise.
With each case, the function author can expect that they if they ask
for X, they will get an X.
I think numeric isnt required anymore, which is good.
Example:
function add_user (+string name, string phone_number, int age, +int
friend_count, resource photo) { ... }
We may bike shed for a while about the choice of +/- vs strict int
or weak int, as well as some of the choices in (S). Lets argue about
the overall idea first, and get to specifics later.
If people like this, I can work on the patch.
Thanks,
Paul
* This is a suggested semantics for (S)
Each line is in the form: Run-time type - type hint = result. You
may read x - y = z as an x passed to a hinted parameter y gives a
z. * means all types I didn't mention explicitly. ?? means reasonable
people may disagree. I would lean towards FAIL in these cases.
array - array = array
* - array = FAIL
numeric string - int = cast to int
real - int = cast to int
int - int = int
* - int = FAIL
int - numeric = int
real - numeric = real
string - numeric = real/int
bool - numeric = ??
* - numeric = FAIL
int - bool = bool
bool - bool = bool
null - bool = false
real - bool = bool
string - bool = bool
* - bool = ??
null - null = null
* - null = FAIL
array - scalar = FAIL
int - scalar = int
bool - scalar = bool
null - scalar = null
real - scalar = real
string - scalar = string
resource - scalar = FAIL
object - scalar = FAIL
MyObj - scalar = FAIL
* - mixed = *
int - real = real
real - real = real
numeric string - real = real
* - real = FAIL
array - string = FAIL
int - string = string
bool - string = FAIL
null - string = FAIL
real - string = string
string - string = string
resource - string = FAIL
object - string = __toString() or FAIL
resource - resource = resource
* - resource = FAIL
object - object = object
MyObj - object = MyObj
* - object = FAIL
MyObj - MyObj = MyObj
* - MyObj = FAIL
* This is a suggested semantics for (H)
Whatever is passed will be cast to whatever you ask for, using
existing casting rules, even if thats stupid.
* This is a suggested semantics for (H)
If you ask for X, it must be X, except:
object with __toString() - string = string
Anything else is FAIL (which I believe is an E_RECOVERABLE_ERROR).
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Flexible type hinting
On 1-Jul-09, at 10:35 PM, Paul Biggar wrote: - A strong argument against (C) is that this currently has no parallel with how scalars are handled in PHP currently. It does not need to have a parallel. PHP as a rule is a type flexible language, my intention is not to change that, simply provide developers with yet another tool they can use to make their life easier and not break anything for people who already use PHP and don't want/need type hinting. The way current internal functions handle input should not change, since doing so will break nearly all existing code. We can provide means for authors as Hannes had pointed our earlier, of new extensions and if we choose to allow it internal methods/functions to have script type hints, but IMHO that only makes sense for future code. - An argument for (H)/(S) is that the manual has been written in this style, using this syntax. Manual has nothing to do with this, manual describes native(!!) PHP functions that should not implement type hints unless we as a team all decide to make PHP type strict, which I don't think is such a good idea. - The (C) crowd suggested numeric and scalar to the (H) crowd, but I dont think they were impressed. If you don't use numeric type for native PHP functions you will break lots of existing code. Remember the goal of this excursive is not to change the nature of PHP, but rather provide a non-destructive feature for people who see the benefit in type hinting within their own code. - I dont think there is a strong case for a strongly typed bool. If function returns -1 on error bool cast will convert it to true, which may not be intent. Look guys, I have been using type hints for quite a long time in PHP, something I doubt most developers here can say. It does not mean people should agree with me or implies that what I say is right, but give the following a bit of consideration before listing your objects. 1) Strict type hinting helps to solve bugs, both the ones made out of careless/missing validation as well as subtle logic bugs that often take hours to resolve. I can tell you that within a week of implementing type hints we've been able to identify 30-40 bugs within a period of day. Many of which would not have been detected with flexible type hints that Paul is suggesting here is one example: A developer was doing select * from table and then using PDO fetchColumn(), on the dev environment table structure was such as the 1st column was a numeric primary key and all worked well. However, in production the order of columns was different and the returned value was actually a login name (varchar), since they happened to be numeric in nature code worked but operated on the wrong ids. It was a very subtle bug that strict type hinting identified instantly and probably saved at least hour's worth of code review. 2) Type hinting will not create a mess of cast to the right types in the code as Stas had suggested, in close to a million lines of PHP code we have, I've been able to find less then 1000 (just did a grep) instances of casts. There is a good reason for that once you get out of the input processing stage you typically (aside from __toString()) have the data in the right type. The code also includes bits from PEAR and external libs like fpdf and guess what those have no type hints and they work along side with type hinted code without any issues. Why? Well, when developers intend to return an int or a float or a boolean, they rarely convert to a string just because they can. 3) Lets not forget that PHP has always been about giving as many tools as possible to our users to help them solve various problems. When I decided to post this patch on this list, thanks largely to encouragement of fellow developers, I've also thrown it on my blog to see what users of PHP think and see if perhaps my specific use case is not applicable in common situations. Of all the replies I see no objection so far and the only complaint (funnily enough) is about existence of IS_NUMERIC. I do not wish to start a flame war or arrive at a wishy washy compromise that does not provide a solid solution. If the majority disagrees with the idea, that's perfectly fine, no harm no foul, I'll keep patching my PHP locally and if I have time maintain a type hinting patch outside of stock php for people to use. But please, don't reject this idea because you personally don't see yourself using it or because you want to avoid having to work in a future with a library/framework that is strict about its input or some far fetched idea that it will change the very nature of PHP. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
