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 :
> 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
[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 (...). My
proposition would be for a "class" attribute to be set instead of the
style attribute, based on the value of $inline (...).
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("");
- zend_printf("\n", last_color);
+ zend_printf("\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("", last_color);
+zend_printf("", last_color);
}
}
switch (token_type) {
@@ -177,7 +177,7 @@
zend_printf("");
}
if (syntax_highlighter_ini->highlight_comment != syntax_highlighter_ini->highlight_html) {
-zend_printf("", syntax_highlighter_ini->highlight_comment);
+zend_printf("", 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_COLOR"phphtml"
+#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, 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
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] RFC: Removing the Zend API
On Wed, Apr 1, 2009 at 3:35 PM, Andi Gutmans 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
2009/4/1 Johannes Schlüter : > 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
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
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] PEAR support in 5.3
2009/4/1 Richard Quadling : > 2009/4/1 Pierre Joye : >> check the snapshot. >> >> On Wed, Apr 1, 2009 at 12:12 PM, Richard Quadling >> wrote: >>> 2009/3/31 Lukas Kahwe Smith : 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=ZEND002498&r=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=ZEND002498&r=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=ZEND002498&r=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] 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\Blah"ed. With your proposal, one would have to check every single one of the meta-files for every class "use"d. 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] RFC: Removing the Zend API
On Tue, Mar 31, 2009 at 9:23 PM, Nuno Lopes 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] PEAR support in 5.3
2009/4/1 Pierre Joye : > check the snapshot. > > On Wed, Apr 1, 2009 at 12:12 PM, Richard Quadling > wrote: >> 2009/3/31 Lukas Kahwe Smith : >>> >>> 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=ZEND002498&r=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=ZEND002498&r=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] User namespaces and PHP classes
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.
Regards,
Stan Vassilev
Hi,
So definetly I need to prepend the \ or declare the "usage" of the
class at the beginning in order to use classes declared in the global
scope? This means SPL classes and 3rd-party classes.
Is there a way to import all the SPL classes at once? ;) (use SPL\*,
use PDO\*).. just wondering.
Thanks
On Tue, Mar 31, 2009 at 5:38 PM, Stan Vassilev | FM
wrote:
Hi,
Try this:
use PDO;
Regards,
Stan Vassilev
-
Hello,
I've been writing in the last days a web application on PHP 5.3 (beta1
although RC was released) cause of all the goodies it brings,
specially the namespaces, however I've been a bit stuck and
*surprised* that the only way to use a PHP class (like Iterators, PDO,
etc) is to call them from the global scope, this means: adding the \
at the beginning at the class.
My short question is: is it the only possible way? That means that I
need to be very careful when invoking PHP classes, like PDO? Currently
when I do:
$pdo = new PDO(..);
throws an error if I use it from one of "my" namespaced-classes, the
error
is:
Fatal error: Class 'MyNameSpace\PDO' not found in /foo/bar/foome.php
throws an error, since spl_autoload can't find the 'MyNameSpace\PDO'
class. And yes I know I could create a class that extends from it, but
I don't think that's the best idea, just imagine the number of classes
I just need to create to cover the PHP classes I plan to use.
So, are there other workarounds for this? Like an autoload function
for PHP objects created inside a non-global scope (MyNameSpace)? I was
reading a thread about namespaces of last year and someone suggested
something like:
if (($p = strrpos($class, '\\')) !== false) {
$name = substr($class, $p+1);
if (class_exists("\\$name")) {
spl_autoload("\\$name");
// or use "\\$name";
return;
}
}
However that wont work cause: 1) one can't use "use" at the middle of
a PHP files, it needs to be used at the beginning afaik, 2)
spl_autoload will definetly find the class I'm passing (supposing PDO)
but it's useless since what is "expected" by PHP is a MyNameSpace\PDO
class. Probably I could use Reflection but I'm not sure if that's the
best idea...
Any other plans to use PHP objects (SPL, PDO, etc) inside non-global
namespaces? Maybe a "PHP" namespace that spl_autoload could catch,
like:
use PHP;
use PHP\SPL;
use PHP\ArrayObject;
(this idea was given in a previous thread :-))
.. or perhaps having something like spl_namespace_alias, when someone
can use inside their autoload functions:
spl_namespace_alias('/PDO', $classname); // where $classname is the
parameter received by the __autoload functions.
I don't have any problems to prepend the "\" but I think PHP should
catch that stuff automatically as it does with constants and
functions, no? Find a bit annoying to write the "\" to PHP classes I
want to use imho.
Thanks!
--
Pablo Fischer (pablo [arroba/at] pablo.com.mx)
--
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
--
Pablo Fischer (pablo [arroba/at] pablo.com.mx)
--
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] PEAR support in 5.3
check the snapshot. On Wed, Apr 1, 2009 at 12:12 PM, Richard Quadling wrote: > 2009/3/31 Lukas Kahwe Smith : >> >> 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=ZEND002498&r=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 -- 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/3/31 Lukas Kahwe Smith : > > 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=ZEND002498&r=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] 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] 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
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
