Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
2009/7/2 Stanislav Malyshev s...@zend.com: It's not about the user input and security - it's about having different parts of your code working together through all possible changes. If you've got strict API you've got to make sure what you are sending to it would pass those strict checks, and would keep doing so through all changes done to the code. Hmm. Sounds like a programmers job you're describing there. I wonder if the split is between people coming to PHP from web design (JavaScript/Perl) and coming to PHP from other programming languages (VB/Java/C++/COBOL/ColdFusion - a long list [1]). I've mainly come from a Delphi's Object Pascal and Sage Retrieve 4GL (syntatically a mix of COBOL and Pascal). A big +1 from me to incorporate type hinting into PHP. I think calling this proposal type hinting just confuses the discussion. It's (optional) strict typing and it should be called so. Maybe this could be solved easier and made more acceptable to all sides if rather than calling it type hinting / (optional) strict typing it was called auto casting. A significant issue is what happens when the variables supplied are NOT of the appropriate type. I agree with Stanislav in that developers could end up with having to stuff their code with explicit type conversions. Inside the function/method, we are wanting to essentially force the inputs to match the requirements. So, rather than have the explicit type conversions being performed by users of the libraries, why not incorporate the conversions into the function/method declaration? If the data coming in is weakly typed, and we are wanting a specific type, we are going to cast it (currently). Casting is going to take place somewhere. Currently, you can use docblocks to suggest the type (no enforcement). If a user DOES read the docblocks and casts it, it doesn't actually help anyone as PHP is known to be weakly typed, so the library developer STILL has to do checks of some sort. But. If autocasting was available, users could RELY on the fact that PHP will use its built-in, well known and documented type-juggling logic to cast the supplied userland data to the libraries required type. This is now really utilising PHP's type-juggling to intelligently provide library developers with optional strict-typing. It incorporates type hinting, so a library user can do the casting if they want (I assume PHP does nothing for (string)1 or (int)4, etc.) Essentially auto casting would remove having to manually cast data at all. Regards, Richard. [1] http://en.wikipedia.org/wiki/Comparison_of_programming_languages#Type_systems -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! I need a car : http://snipurl.com/l4pih ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
2009/7/2 Stanislav Malyshev s...@zend.com: Hi! function func(int $i) for strict type checking, and function func((int)$i) Without saying anything on the merits of having both syntaxes, visually I think this looks much nicer, even with the disadvantage of parentheses overload. Oh look, auto-casting. And __cast() is excellent, but would be at odds with __toString(). And then having __toBoolean(), __toInteger(), etc. might be a bit OTT. How about __cast($type [,$class]) where $type is one of the T_xxx_CAST constants and class is the required class for a class casting? (See nearly already there!) T_ARRAY_CAST T_BOOL_CAST T_DOUBLE_CAST T_INT_CAST T_OBJECT_CAST T_STRING_CAST -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! I need a car : http://snipurl.com/l4pih ZOPA : http://uk.zopa.com/member/RQuadling -- 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
2009/7/1 Ilia Alshanetsky i...@prohost.org:
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.
Brilliant stuff Ilia!
One thing I noticed in the patch is:
+ST_IN_SCRIPTING(string|binary|unicode) {
+ return T_STRING_HINT;
+}
which makes sense if we keep for PHP6 but doesn't for 5_3 which afaik
doesn't have (unicode) casting yet :) I think that's nitpicking I
agree and I just want to make sure that this doesn't become a
documentation issue for people who'd think you can hint using unicode
or even see article saying you can hint with unicode.
Makes sense for PHP6 though but since you merged your patch from 5.2 I
figured I could ask :)
Apart from that this is awesome and am I glad that we are not trying
to cast automatically!
+1
--
Slan,
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Flexible type hinting
Hi Ilia,
On Thu, Jul 2, 2009 at 3:35 AM, Paul Biggarpaul.big...@gmail.com wrote:
Thanks to Ilia for getting to ball rolling on scalar type hinting.
I believe I have a solution that caters to each crowd, without being
too complicated.
My impression is that there only minor support for the flexible
approach, and that even then, everyone prefers strict checking by
default. So the ideal seems to be your patch, with the addition of
function x ((int) $casted_parameter) { ... }
Since this can be built as an extra step on top of your patch, this
can be added later (although it would obviously be great if you
preferred to add it now...). I recommend you proceed with the next
step of getting your patch accepted (I presume an RFC or something).
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
Hi Ilia, Your patch doesn't support a null (or maybe it should be called unset) type check. Its uses would be rare, but I think it should be present for completeness. Thanks, Paul On Wed, Jul 1, 2009 at 5:59 PM, Ilia Alshanetskyi...@prohost.org wrote: There has been quite a bit of discussion on this list, IRC, developer meetings, etc... about introduction of type hinting to PHP. Most people appear to think that this would be a good idea, but there is a reason why it is not in PHP already. The main source of conflict appears to be that in some cases typical type hinting is just too strict for PHP's typeless nature (most people expect that 1 == 1, while int type hint would definitely reject string 1). Personally, I disagree with that opinion, but I can understand people who raise that issue. At work we've been using PHP 5.2 with type hinting for nearly 2 years now with great success, it makes code much easier to read and understand and the security benefit of type hinting is not to be under valued. In many cases type hinting can present a last line of defense against unexpected input for numeric fields, which are typically abused to do SQL injection. I've taken a few hours this morning to port my 5.2 type hinting patch to 5.3. In recognition of a need for a more 'flexible' numeric type I've introduced (numeric) type hint that would allow bool/int/float data types as well as a string containing a numeric entity as identified by is_numeric_string(). For completion i've also added (scalar) data type that will allow any scalar data element. The patch is available here: http://ia.gd/patch/type_hint_53.txt It should be noted that this patch is fully compatible with opcode caches and and requires no changes on the part of an opcode cache such as APC to work. My hope is that the latest changes will allow this to become a standard part of PHP. Ilia Alshanetsky P.S. It should be noted that this is not the first idea for type hints, that credit goes to Hannes Magnusson who had posted a similar patch on the internals list back in 2006. Also, back in 2008 Felipe Pena wrote a type hinting patch for PHP that is available on wiki.php.net. -- 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
Hi Ilia,
On Wed, Jul 1, 2009 at 7:07 PM, Stanislav Malyshevs...@zend.com wrote:
The patch is available here: http://ia.gd/patch/type_hint_53.txt
Technical comment: as this patch changes binary API this shouldn't happen in
5.3 branch. So maybe it's better to make it for 6.
Index: Zend/zend_compile.h
===
RCS file: /repository/ZendEngine2/zend_compile.h,v
retrieving revision 1.316.2.8.2.12.2.40
diff -u -p -a -d -u -r1.316.2.8.2.12.2.40 zend_compile.h
--- Zend/zend_compile.h 5 Jun 2009 23:20:59 - 1.316.2.8.2.12.2.40
+++ Zend/zend_compile.h 1 Jul 2009 16:45:02 -
@@ -175,7 +175,7 @@ typedef struct _zend_arg_info {
zend_uint name_len;
const char *class_name;
zend_uint class_name_len;
- zend_bool array_type_hint;
+ zend_uint type_hint;
zend_bool allow_null;
zend_bool pass_by_reference;
zend_bool return_reference;
I think you could make this work for 5.3, if it used the old
zend_bool array_type_hint. A zend_bool is 8 bits, so that's plenty.
It would be a little bit messy, but I'm fairly confident it could be
made work.
Thanks,
Paul
--
Paul Biggar
paul.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
Good point, this way API could remain the same.
On 3-Jul-09, at 9:31 AM, Paul Biggar wrote:
Hi Ilia,
On Wed, Jul 1, 2009 at 7:07 PM, Stanislav Malyshevs...@zend.com
wrote:
The patch is available here: http://ia.gd/patch/type_hint_53.txt
Technical comment: as this patch changes binary API this shouldn't
happen in
5.3 branch. So maybe it's better to make it for 6.
Index: Zend/zend_compile.h
===
RCS file: /repository/ZendEngine2/zend_compile.h,v
retrieving revision 1.316.2.8.2.12.2.40
diff -u -p -a -d -u -r1.316.2.8.2.12.2.40 zend_compile.h
--- Zend/zend_compile.h 5 Jun 2009 23:20:59 - 1.316.2.8.2.12.2.40
+++ Zend/zend_compile.h 1 Jul 2009 16:45:02 -
@@ -175,7 +175,7 @@ typedef struct _zend_arg_info {
zend_uint name_len;
const char *class_name;
zend_uint class_name_len;
- zend_bool array_type_hint;
+ zend_uint type_hint;
zend_bool allow_null;
zend_bool pass_by_reference;
zend_bool return_reference;
I think you could make this work for 5.3, if it used the old
zend_bool array_type_hint. A zend_bool is 8 bits, so that's plenty.
It would be a little bit messy, but I'm fairly confident it could be
made work.
Thanks,
Paul
--
Paul Biggar
paul.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] Re: Flexible type hinting
On 03.07.2009, at 15:04, Paul Biggar wrote:
Hi Ilia,
On Thu, Jul 2, 2009 at 3:35 AM, Paul Biggarpaul.big...@gmail.com
wrote:
Thanks to Ilia for getting to ball rolling on scalar type hinting.
I believe I have a solution that caters to each crowd, without being
too complicated.
My impression is that there only minor support for the flexible
approach, and that even then, everyone prefers strict checking by
default. So the ideal seems to be your patch, with the addition of
function x ((int) $casted_parameter) { ... }
hmm not sure that the consensus of a weak check would be an
automatic cast. Actually that wouldnt be much of a check in that case.
I think the other side is more asking for what Ilia already begun with
numeric in the sense of a weak checker. After the check it could go
ahead and cast too for all I care, but it shouldnt be the equivalent
of a cast. But maybe you are not implying that and I am just getting
confused by the syntax.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
Hi Lukas, On Fri, Jul 3, 2009 at 2:35 PM, Lukas Kahwe Smithm...@pooteeweet.org wrote: hmm not sure that the consensus of a weak check would be an automatic cast. Actually that wouldnt be much of a check in that case. I think the other side is more asking for what Ilia already begun with numeric in the sense of a weak checker. After the check it could go ahead and cast too for all I care, but it shouldnt be the equivalent of a cast. But maybe you are not implying that and I am just getting confused by the syntax. I think people wanted an automatic cast for the weak check. The idea would be that if you hinted (int), you could be guaranteed that you got an int. The syntax was suggested (I believe, it wasn't my suggestion) to look like casting. 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] Re: Flexible type hinting
Ford, Mike wrote: function func(int $i) for strict type checking, and function func((int)$i) for coercion aka casting (although now I've seen it written down I'm not so sure! ;). I had thought about having weak and strong' type checking even before Paul sent his proposal, but I rejected the idea myself for the confusion it might cause because I couln't think of a good syntax. This one actually looks pretty good, it's intuitive and consistent with what the language offers now. Big +1 regards Rodrigo Saboya -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On 03.07.2009, at 15:04, Paul Biggar wrote: Since this can be built as an extra step on top of your patch, this can be added later (although it would obviously be great if you preferred to add it now...). I recommend you proceed with the next step of getting your patch accepted (I presume an RFC or something). Going by Ilia's comments about RFC's on IRC, I guess someone else should take on writing an RFC, summarizing the discussion, linking important ml posts and moving forward with a vote, keeping in account the various relevant options/variations suggested. This RFC here can serve as a starting point: http://wiki.php.net/rfc/typehint Remember anyone can request a wiki account and do this. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Veracity of statement that FastCGI is always enabled cannot be disabled in PHP 5.3
Hi. I'm the maintainer of PHP in MacPorts and I'm in the process of updating our php5 port to version 5.3.0. I originally posted this message to the php-install list but was asked via private mail from Christopher Jones to re-post it here on the internals list. http://marc.info/?l=php-installm=124654253527650w=2 In PHP 5.2.x and earlier you had to choose which web SAPI you wanted -- Apache 1, Apache 2, or FastCGI. The CLI SAPI was always built in any case, in addition to the web SAPI you selected, but you couldn't have both an Apache SAPI and the FastCGI SAPI built at the same time; you had to run ./configure and make twice each, and this is what my php5 port currently does to allow a user to install both an Apache SAPI and the FastCGI SAPI at the same time if desired. On http://www.php.net/manual/en/migration53.sapi.php it says of PHP 5.3 that FastCGI is now always enabled and can not be disabled. See sapi/cgi/CHANGES for more details. The same text appears in the NEWS file. In sapi/cgi/CHANGES it says Now fastcgi is always enabled. Based on these statements, I assumed the FastCGI SAPI would now always be built, just like the CLI SAPI always gets built. But it appears that if you use --with-apxs2 or --with-apxs, PHP 5.3 does in fact disable the FastCGI SAPI, and only builds the Apache and CLI SAPIs, just like PHP 5.2.x did. sapi/cgi/CHANGES also states In PHP5.3 all additional configure options (except --enable-cgi) are removed and ./configure --help lists the option --disable-cgi Disable building CGI version of PHP. Using --disable-cgi, the FastCGI module does not get built. So I believe the statement FastCGI is now always enabled is false, because FastCGI is not enabled if you request an Apache SAPI. And I believe the statement that it can not be disabled is false, because the --disable-cgi configure argument does disable it. I believe the correct documentation of PHP 5.3's capabilities would be, The FastCGI module is now built by default, but can be disabled by using --disable-cgi. Note: I did the above tests using 5.3.0RC4 not 5.3.0 final. This is my first time posting to a PHP mailing list. I wanted to check here for guidance before filing a bug for these issues. I searched Google and the mailing list archive at marc.info and couldn't find a prior discussion of these issues relating to PHP 5.3, but if there is one and I've missed it I'd of course appreciate a link to it. P.S: There is a typo on the mailing lists page's description of the php-install list. It says How to install PHP with partiucular configurations, and servers. That should be particular not partiucular and the comma should be removed. http://www.php.net/mailing-lists.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Veracity of statement that FastCGI is always enabled cannot be disabled in PHP 5.3
I apologize for the top-quoting, but it seemed appropriate here. It seems the language of the documentation is unclear. It is not that the CGI SAPI (now called the CGI-FCGI SAPI) is always built, in the fashion of CLI. It is, precisely, that the FastCGI support within the CGI SAPI can no longer be turned off. However, the SAPI selection process still procedes as it did before. I'll see what we can do about clarifying the documentation. Sorry for the confusion :). -- Gwynne On Jul 3, 2009, at 11:39 AM, Ryan Schmidt wrote: Hi. I'm the maintainer of PHP in MacPorts and I'm in the process of updating our php5 port to version 5.3.0. I originally posted this message to the php-install list but was asked via private mail from Christopher Jones to re-post it here on the internals list. http://marc.info/?l=php-installm=124654253527650w=2 In PHP 5.2.x and earlier you had to choose which web SAPI you wanted -- Apache 1, Apache 2, or FastCGI. The CLI SAPI was always built in any case, in addition to the web SAPI you selected, but you couldn't have both an Apache SAPI and the FastCGI SAPI built at the same time; you had to run ./configure and make twice each, and this is what my php5 port currently does to allow a user to install both an Apache SAPI and the FastCGI SAPI at the same time if desired. On http://www.php.net/manual/en/migration53.sapi.php it says of PHP 5.3 that FastCGI is now always enabled and can not be disabled. See sapi/cgi/CHANGES for more details. The same text appears in the NEWS file. In sapi/cgi/CHANGES it says Now fastcgi is always enabled. Based on these statements, I assumed the FastCGI SAPI would now always be built, just like the CLI SAPI always gets built. But it appears that if you use --with-apxs2 or --with-apxs, PHP 5.3 does in fact disable the FastCGI SAPI, and only builds the Apache and CLI SAPIs, just like PHP 5.2.x did. sapi/cgi/CHANGES also states In PHP5.3 all additional configure options (except --enable-cgi) are removed and ./configure --help lists the option --disable-cgi Disable building CGI version of PHP. Using --disable-cgi, the FastCGI module does not get built. So I believe the statement FastCGI is now always enabled is false, because FastCGI is not enabled if you request an Apache SAPI. And I believe the statement that it can not be disabled is false, because the --disable-cgi configure argument does disable it. I believe the correct documentation of PHP 5.3's capabilities would be, The FastCGI module is now built by default, but can be disabled by using --disable-cgi. Note: I did the above tests using 5.3.0RC4 not 5.3.0 final. This is my first time posting to a PHP mailing list. I wanted to check here for guidance before filing a bug for these issues. I searched Google and the mailing list archive at marc.info and couldn't find a prior discussion of these issues relating to PHP 5.3, but if there is one and I've missed it I'd of course appreciate a link to it. P.S: There is a typo on the mailing lists page's description of the php-install list. It says How to install PHP with partiucular configurations, and servers. That should be particular not partiucular and the comma should be removed. http://www.php.net/mailing-lists.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! I think you could make this work for 5.3, if it used the old zend_bool array_type_hint. A zend_bool is 8 bits, so that's plenty. It would be a little bit messy, but I'm fairly confident it could be made work. Unless the particular module would interpret everything that has non-zero array_type_hint as being typehinted to array, as it is now in 5.3.0. -- Stanislav Malyshev, Zend Software Architect 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! I wonder if the split is between people coming to PHP from web design (JavaScript/Perl) and coming to PHP from other programming languages (VB/Java/C++/COBOL/ColdFusion - a long list [1]). I've mainly come I've learned Java in about '96 and Perl around the same time. I wonder which box you'd want to put me in :) Maybe this could be solved easier and made more acceptable to all sides if rather than calling it type hinting / (optional) strict typing it was called auto casting. But as proposed it's not casting, unlike (string) - which is casting - it would just reject the variable that is not string, without any attempt to convert type. It's strict typing, just like C or Java do. So, rather than have the explicit type conversions being performed by users of the libraries, why not incorporate the conversions into the function/method declaration? That's what I was saying from the start. :) -- Stanislav Malyshev, Zend Software Architect 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
