Re: [PHP-DEV] GSoC - XDebug profiling web front-end
Hi. On 31.03.2009 18:08 Uhr, David Coallier wrote: I'm sorry to tell you that but xdebug web profiling was a project for last year. Please read http://wiki.php.net/gsoc/2009 for this years GSoC ideas. Well, was it done last year? If yes: great, where is it? If no: yeah, do it this year! Regards, Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC - XDebug profiling web front-end
On Wed, 1 Apr 2009, Karsten Dambekalns wrote: On 31.03.2009 18:08 Uhr, David Coallier wrote: I'm sorry to tell you that but xdebug web profiling was a project for last year. Please read http://wiki.php.net/gsoc/2009 for this years GSoC ideas. Well, was it done last year? If yes: great, where is it? If no: yeah, do it this year! There was something, it's in my CVS (srmread:srmr...@cvs.xdebug.org:/repository co xdebug-web) or http://cvs.xdebug.org/cgi-bin/viewvc.cgi/xdebug-web/ I don't know what the state is tbh, but there is now also webgrind at http://code.google.com/p/webgrind/ regards, Derick -- http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org twitter: derickrethans -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC - XDebug profiling web front-end
Derick Rethans schrieb: I don't know what the state is tbh, but there is now also webgrind at http://code.google.com/p/webgrind/ There is also Carica Cachegrind (http://ccg.sourceforge.net/). -- 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] PEAR support in 5.3
2009/4/1 Pierre Joye pierre@gmail.com: check the snapshot. On Wed, Apr 1, 2009 at 12:12 PM, Richard Quadling rquadl...@googlemail.com wrote: 2009/3/31 Lukas Kahwe Smith m...@pooteeweet.org: On 28.03.2009, at 16:45, Ionut G. Stan wrote: Hi, I'm playing with 5.3.0 RC1 and wanted to install PEAR. In the previous versions (for Windows at least) there was a go-pear executable which is missing now. So what are the plans for supporting PEAR in this new PHP version? Just FYI ... seems like Pierre fixed that one. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I've just downloaded all the win32 RC versions from http://windows.php.net/qa/ (x86 and x64 versions). There is no PEAR directory, or go-pear.bat file or anything. The only mention of PEAR is in the install.txt files (which specifically names the pear folder and go-pear.bat file. The install.txt file still mentions the php5isapi.dll SAPI file which is no longer built for distribution. Richard. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre http://blog.thepimp.net | http://www.libgd.org I really wish I could say that I can see them! php-5.3-win32-VC9-x86-latest has files dated 2009/04/01 12:50 php-5.3-nts-win32-VC9-x86-latest has files dated 2009/04/01 12:59 php-5.3-win32-VC6-x86-latest has files dates 2009/04/01 13:07 php5.3-nts-win32-VC6-x86-latest has files dated 2009/04/01 13:15 No files containing the name pear. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Removing the Zend API
On Tue, Mar 31, 2009 at 9:23 PM, Nuno Lopes nlop...@php.net wrote: Hi Paul et all, I fully understand (and even share) your motivations and goals. However it seems to me that describing an extension in PHP will lead to loss of performance, as you cannot capture certain C features in PHP. For example, there are some internal functions that rely on pointer arithmetic to get decent performance. This is not about capturing every C feature. Instead, it is about strictly separating the C and PHP code. If someone wants to C pointer arithmetic, it is simple to code it on the C side of the line. Its not necessary to expose the exact C function from the library. Sometime, you may wish to to have a C function wrapping it, to do some dirty tricks. Then you may extend to PHP to better capture these dirty tricks, and then you'll end up with some DSL for building PHP extensions. It's not necessarily bad, it's just a lot of work.. :) This - which I'll call the Pyrex model - is one way to go, but its not my preference. While I think it beats the current model, I hope that it won't be required with whatI propose in the RFC. Moreover, in your example in the wiki you don't include how you would do parameter parsing. Or do you rely on the code generator to look at the C functions signatures and figure out by itself what to do? (actually there is some ambiguity, AFAIR, and thus guessing cannot be done reliably) That is exactly right. (I'll make this clearer in the RFC). I can't think of any cases where guess cannot be done reliably. If you can give me an example, I'll try and address it. To summarize my e-mail, I believe this is a very interesting idea, but needs a lot more thinking :) It's a nice SoC project nethertheless. It certainly does need more thinking, and I'm hoping that people can pick holes in it, so that I can fill them. A SoC project would be ideal, as it would probably expose - and hopefully solve - a great deal of flaws. Thanks for your comments, I'll try and update the RFC in response. Paul - Original Message - Hi, I've added a new RFC to the wiki (http://wiki.php.net/rfc/remove_zend_api). It details a plan to try and decouple the Zend engine from the libraries, in order to allow large scale changes to the Zend engine in the future. The RFC describes a prototype phase of the project, which could reasonably be done within a GSOC project, so I have added it to the GSOC 09 page (http://wiki.php.net/gsoc/2009#prototyping_removal_of_the_zend_api). If anybody has any comments, I'd be delighted to hear them. If anybody knows (or is) a good student looking for a GSOC project (and I've left it late, there are only 3 days left to apply), please encourage the student to look at this. Finally, if anybody is interested in helping mentor this as part of the GSOC, I'd be grateful for the help (I have to start writing my thesis soon). 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] User namespaces and PHP classes
Stan Vassilev | FM wrote: Hi, There is a way to implement in some future release of PHP (without hurting performance), but it's not in the scope of 5.3. Each namespace should have a meta file listing all symbols present in it. The parser loads that static file at parse time and resolves all naming at parse time, leaving autoload to figure out only where a symbol is, not whether it's present. I've not noticed great interest in this approach last time I offered it. Hi Stan, The reason there is little to no enthusiasm about this idea is that it would make developing less robust while giving the illusion of ease. let's say you have this line of code: $a = new Blah(); Currently, the class name is deterministic. It's either (1) namespace\Blah() or (2) whatever we use nsname\Blahed. With your proposal, one would have to check every single one of the meta-files for every class used. This would mean code review becomes impossible. Is it really worth saving a few type-one-time-and-forget-about-it use statements for this terrible risk? I think not. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PEAR support in 5.3
2009/4/1 Richard Quadling rquadl...@googlemail.com: 2009/4/1 Pierre Joye pierre@gmail.com: check the snapshot. On Wed, Apr 1, 2009 at 12:12 PM, Richard Quadling rquadl...@googlemail.com wrote: 2009/3/31 Lukas Kahwe Smith m...@pooteeweet.org: On 28.03.2009, at 16:45, Ionut G. Stan wrote: Hi, I'm playing with 5.3.0 RC1 and wanted to install PEAR. In the previous versions (for Windows at least) there was a go-pear executable which is missing now. So what are the plans for supporting PEAR in this new PHP version? Just FYI ... seems like Pierre fixed that one. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I've just downloaded all the win32 RC versions from http://windows.php.net/qa/ (x86 and x64 versions). There is no PEAR directory, or go-pear.bat file or anything. The only mention of PEAR is in the install.txt files (which specifically names the pear folder and go-pear.bat file. The install.txt file still mentions the php5isapi.dll SAPI file which is no longer built for distribution. Richard. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre http://blog.thepimp.net | http://www.libgd.org I really wish I could say that I can see them! php-5.3-win32-VC9-x86-latest has files dated 2009/04/01 12:50 php-5.3-nts-win32-VC9-x86-latest has files dated 2009/04/01 12:59 php-5.3-win32-VC6-x86-latest has files dates 2009/04/01 13:07 php5.3-nts-win32-VC6-x86-latest has files dated 2009/04/01 13:15 No files containing the name pear. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! And the next lot of win32 snapshots. Still no PEAR. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Removing the Zend API
Hi, On Wed, 2009-04-01 at 14:24 +0100, Paul Biggar wrote: Moreover, in your example in the wiki you don't include how you would do parameter parsing. Or do you rely on the code generator to look at the C functions signatures and figure out by itself what to do? (actually there is some ambiguity, AFAIR, and thus guessing cannot be done reliably) That is exactly right. (I'll make this clearer in the RFC). I can't think of any cases where guess cannot be done reliably. If you can give me an example, I'll try and address it. Well, take your example: void Y(char *, int) Is the second parameter the length of the string or something independent? Is the char* changed? And who is going to free it? johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Removing the Zend API
Hi Paul, This is something I have considered in the past esp. as it would also reduce dependency of extensions on PHP runtime and make it easier for 3rd parties to distribute PHP extensions which don't have to be rebuilt per-PHP version. This is similar to JNI. There are some real challenges though and JNI is a good example of those challenges. In order to completely abstract the API from data structure you need higher level API calls esp. for things like arrays and objects which typically incur a significant performance loss. JNI sucks big time on that front. Also it often leads to additional data copying. Also this doesn't necessarily have to replace the Zend API but in fact be an engine independent API. Over time if everyone adopts then we could get rid of Zend API. However, if what I say above is correct, we may find that it's actually very complementary and that some core extensions prefer to hook into the engine very tightly while third parties (e.g. pdflib) and less core extensions prefer to stick to an independent API which can work across not only mini release of PHP but also minor and in some cases major release of PHP. This API would need to be designed in great detail and we would need to make sure it is long lasting. My 2 cents. Andi -Original Message- From: Paul Biggar [mailto:paul.big...@gmail.com] Sent: Monday, March 30, 2009 4:07 PM To: PHP Internals Subject: [PHP-DEV] RFC: Removing the Zend API Hi, I've added a new RFC to the wiki (http://wiki.php.net/rfc/remove_zend_api). It details a plan to try and decouple the Zend engine from the libraries, in order to allow large scale changes to the Zend engine in the future. The RFC describes a prototype phase of the project, which could reasonably be done within a GSOC project, so I have added it to the GSOC 09 page (http://wiki.php.net/gsoc/2009#prototyping_removal_of_the_zend_api). If anybody has any comments, I'd be delighted to hear them. If anybody knows (or is) a good student looking for a GSOC project (and I've left it late, there are only 3 days left to apply), please encourage the student to look at this. Finally, if anybody is interested in helping mentor this as part of the GSOC, I'd be grateful for the help (I have to start writing my thesis soon). 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: Removing the Zend API
2009/4/1 Johannes Schlüter johan...@schlueters.de: Hi, On Wed, 2009-04-01 at 14:24 +0100, Paul Biggar wrote: Moreover, in your example in the wiki you don't include how you would do parameter parsing. Or do you rely on the code generator to look at the C functions signatures and figure out by itself what to do? (actually there is some ambiguity, AFAIR, and thus guessing cannot be done reliably) That is exactly right. (I'll make this clearer in the RFC). I can't think of any cases where guess cannot be done reliably. If you can give me an example, I'll try and address it. Well, take your example: void Y(char *, int) Is the second parameter the length of the string or something independent? Is the char* changed? And who is going to free it? Good points. I had initially thought that there should be some simple declarative DSL, and later thought 'why can't it be a header file in the simple case'. I guess this is why. I think that to handle more complex cases we need the kind of information which makes it straightforward to easily generate code to make a seamless interface between C and the engine API. The only case I had thought of was to somehow mangle structs/pointers into resources. But I suppose we need lengths for strings. I expect (many?) more of these cases will come up. (Of course, this is why I recommended a SoC project to try it) Thanks for the comments, I'll update the RFC. 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: Removing the Zend API
On Wed, Apr 1, 2009 at 3:35 PM, Andi Gutmans a...@zend.com wrote: Hi Paul, This is something I have considered in the past esp. as it would also reduce dependency of extensions on PHP runtime and make it easier for 3rd parties to distribute PHP extensions which don't have to be rebuilt per-PHP version. This is similar to JNI. It is similar to JNI. This has been done many times before for many languages, including Pythons Pyrex and ctypes, Ruby's FFI, Java's JNI and JNA, and no doubt countless others. The only difference here is that I recommend that we made this the _only_ interface (or as close as we can make it) from the interpreter internals. There are some real challenges though and JNI is a good example of those challenges. In order to completely abstract the API from data structure you need higher level API calls esp. for things like arrays and objects which typically incur a significant performance loss. JNI sucks big time on that front. Also it often leads to additional data copying. All of this happens at the moment to marshal data into zvals. My RFC does not intend to add to this complexity, but rather to make it work exactly the same as it does now. So if currently a library avoids copying values, it should be possible to keep that property. If the library cannot currently avoid it, I do not expect to be able to avoid it with a new scheme. This is very much more important for PHP that JNI is to Java. Every library shipped with PHP (including most of SPL I believe) is tightly coupled to the interpreter. By contrast, the vast majority of Java's Class library is written in Java. Also this doesn't necessarily have to replace the Zend API but in fact be an engine independent API. Over time if everyone adopts then we could get rid of Zend API. However, if what I say above is correct, we may find that it's actually very complementary and that some core extensions prefer to hook into the engine very tightly while third parties (e.g. pdflib) and less core extensions prefer to stick to an independent API which can work across not only mini release of PHP but also minor and in some cases major release of PHP. It doesn't have to, but I think it should. But it would be insane to expect a new scheme to replace the current one, unless it works universally. Core extensions, like important array and string functions, will probably need to be tightly coupled to the interpreter. Some other extensions would too, like Xdebug. If people could suggest other extensions which should not be decoupled, I would appreciate it. This API would need to be designed in great detail and we would need to make sure it is long lasting. I could not agree more. My 2 cents. Andi Thanks for the input, the more the merrier :) Paul -Original Message- From: Paul Biggar [mailto:paul.big...@gmail.com] Sent: Monday, March 30, 2009 4:07 PM To: PHP Internals Subject: [PHP-DEV] RFC: Removing the Zend API Hi, I've added a new RFC to the wiki (http://wiki.php.net/rfc/remove_zend_api). It details a plan to try and decouple the Zend engine from the libraries, in order to allow large scale changes to the Zend engine in the future. The RFC describes a prototype phase of the project, which could reasonably be done within a GSOC project, so I have added it to the GSOC 09 page (http://wiki.php.net/gsoc/2009#prototyping_removal_of_the_zend_api). If anybody has any comments, I'd be delighted to hear them. If anybody knows (or is) a good student looking for a GSOC project (and I've left it late, there are only 3 days left to apply), please encourage the student to look at this. Finally, if anybody is interested in helping mentor this as part of the GSOC, I'd be grateful for the help (I have to start writing my thesis soon). Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- 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: Removing the Zend API
Hi, On Wed, 2009-04-01 at 16:16 +0100, Paul Biggar wrote: I think that to handle more complex cases we need the kind of information which makes it straightforward to easily generate code to make a seamless interface between C and the engine API. The only case I had thought of was to somehow mangle structs/pointers into resources. But I suppose we need lengths for strings. I expect (many?) more of these cases will come up. Well, as soon as any pointer exists you need manual work for a special case. And even when only using integers it's not fully fast-forward: There are cases where not the full integer range is allowed but just a few flags or some specific range. C programmers will know that, passing that 1:1 to PHP userland can be bad. For simple cases http://pecl.php.net/package/ffi might be enough, for average cases there are just a few APIs (PHP_FUNCTION, zend_parse_parameters, RETURN_*) one has to know for a start for an extensions, Hartmut's CodeGen_PECL abstracts that using some XML and then there's PEAR's Inline_C as some weird approach. I'd be happy to have some simple toolkit for this, but I guess it's really hard to make some easy tool which really works in average cases not just in proof-of-concept cases. This might also be interesting for other projects like ProjectZero (PHP using a JVM) or pipp (using Parrot) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Returning NULL when arg parsing fails - was: Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/pcntl pcntl.c /ext/pcntl/tests pcntl_signal.phpt
Hi, After a quick discussion with Lukas and Antony on IRC, I wrote a small script to detect how many functions/methods are returning false after failing to validate the arguments: you 'll find the result for PHP_5_3 attached. The regex I've used is not perfect, but if you think it's somewhat accurate we might want to decide fixing in PHP 5.3 as there aren't many places that need to be fixed. I don't mean to stress you on this, it's not too bad if we don't fix it. But I'd just need a suggestion on what to do within the pdo extension as I'm supposed to commit a fix for PDO::query() and PDO::setFetchMode() to make argument validation more strict and those methods are among the ones that return false when argument checks fail. You'll find a patch for the entire 5.3 php-src, in case you want to take a look: http://www.beccati.com/misc/php/zend_parse_params_return_false.diff Cheers -- Matteo Beccati OpenX - http://www.openx.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Update to Zend Highlighter
Hello everyone,
I'd like to propose a very small update, which would have no
backwards-compatibility problems, and would bring PHP closer to
standards compliance.
The update I'd like to propose is to the Zend Highlighter for PHP,
specifically related to the highlight_file and highlight_string
functions, as well as the php -s command.
My proposal is a very simple one, which would add a third parameter,
which would be optional, which would select between inline styling,
and external styling. The proposed syntax for highlight_file would be:
mixed highlight_file (string $filename [, bool $return= false [, bool
$inline= true]]);
Currently, syntax highlighting is done inline, by means of the style
attribute of the span tag (span style=color: #FF.../span). My
proposition would be for a class attribute to be set instead of the
style attribute, based on the value of $inline (span
class=phpcomment.../span).
The issue this modification is intended to fix is that many developers
who intend to provide syntax highlighting in their project end up
rolling their own code for such. By providing external styling code
rather than inline styling, it makes it possible to modify the style of
all highlighted code, without modifying the code itself. It also
provides the capability to extend the viewing experience with
Javascript, such as code folding functionality.
I've taken the liberty to produce a very quick and dirty patch, which is
by no means complete, but provides a cursory example of what I intend.
I'd like to clarify that this is the first time I've modified PHP's
code, and I know very little C. The only modifications I've done for PHP
in the past have been in the PHP-GTK branch, attempting to fix the
documentation generator to work with the non-standard extension
structure. If I've submitted my proposal poorly, I apologize.
Please offer any comments you have.
Thank you,
Justin Martin aka FrozenFire
Index: Zend/zend_highlight.c
===
RCS file: /repository/ZendEngine2/zend_highlight.c,v
retrieving revision 1.49.2.3.2.2.2.6
diff -u -r1.49.2.3.2.2.2.6 zend_highlight.c
--- Zend/zend_highlight.c 31 Dec 2008 11:15:32 - 1.49.2.3.2.2.2.6
+++ Zend/zend_highlight.c 2 Apr 2009 03:33:35 -
@@ -95,7 +95,7 @@
char *next_color;
zend_printf(code);
- zend_printf(span style=\color: %s\\n, last_color);
+ zend_printf(span class=\%s\\n, last_color);
/* highlight stuff coming back from zendlex() */
token.type = 0;
while ((token_type=lex_scan(token TSRMLS_CC))) {
@@ -139,7 +139,7 @@
}
last_color = next_color;
if (last_color != syntax_highlighter_ini-highlight_html) {
-zend_printf(span style=\color: %s\, last_color);
+zend_printf(span class=\%s\, last_color);
}
}
switch (token_type) {
@@ -177,7 +177,7 @@
zend_printf(/span);
}
if (syntax_highlighter_ini-highlight_comment != syntax_highlighter_ini-highlight_html) {
-zend_printf(span style=\color: %s\, syntax_highlighter_ini-highlight_comment);
+zend_printf(span class=\%s\, syntax_highlighter_ini-highlight_comment);
}
}
zend_html_puts(LANG_SCNG(yy_text), (LANG_SCNG(yy_limit) - LANG_SCNG(yy_text)) TSRMLS_CC);
Index: Zend/zend_highlight.h
===
RCS file: /repository/ZendEngine2/zend_highlight.h,v
retrieving revision 1.25.2.1.2.1.2.2
diff -u -r1.25.2.1.2.1.2.2 zend_highlight.h
--- Zend/zend_highlight.h 31 Dec 2008 11:15:32 - 1.25.2.1.2.1.2.2
+++ Zend/zend_highlight.h 2 Apr 2009 03:33:35 -
@@ -22,12 +22,12 @@
#ifndef ZEND_HIGHLIGHT_H
#define ZEND_HIGHLIGHT_H
-#define HL_COMMENT_COLOR #FF8000/* orange */
-#define HL_DEFAULT_COLOR #BB/* blue */
-#define HL_HTML_COLOR#00/* black */
-#define HL_STRING_COLOR #DD/* red */
-#define HL_BG_COLOR #FF/* white */
-#define HL_KEYWORD_COLOR #007700/* green */
+#define HL_COMMENT_COLOR phpcomment
+#define HL_DEFAULT_COLOR phpdefault
+#define HL_HTML_COLORphphtml
+#define HL_STRING_COLOR phpstring
+#define HL_BG_COLOR phpbackground
+#define HL_KEYWORD_COLOR phpkeyword
typedef struct _zend_syntax_highlighter_ini {
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Returning NULL when arg parsing fails - was: Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/pcntl pcntl.c /ext/pcntl/tests pcntl_signal.phpt
Hi Matteo
2009/4/1 Matteo Beccati p...@beccati.com:
Hi,
After a quick discussion with Lukas and Antony on IRC, I wrote a small
script to detect how many functions/methods are returning false after
failing to validate the arguments: you 'll find the result for PHP_5_3
attached.
The regex I've used is not perfect, but if you think it's somewhat
accurate we might want to decide fixing in PHP 5.3 as there aren't many
places that need to be fixed.
I don't mean to stress you on this, it's not too bad if we don't fix it.
But I'd just need a suggestion on what to do within the pdo extension as I'm
supposed to commit a fix for PDO::query() and PDO::setFetchMode() to make
argument validation more strict and those methods are among the ones that
return false when argument checks fail.
You'll find a patch for the entire 5.3 php-src, in case you want to take a
look:
http://www.beccati.com/misc/php/zend_parse_params_return_false.diff
Most of php-src uses validation check the other way around:
if (zend_parse_parameters(...) == FAILURE) {
...
}
But I still don't agree that we should change to return false if
parameter parsing fails, in most cases it generates a verbal warning
which no one want in first place with this new API which should make
people awake of their code is wrong. Ofcourse theres the quite option,
but still
Cheers
--
Matteo Beccati
OpenX - http://www.openx.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
