RE: [PHP-DEV] Simple Namespace Proposal
Hi Derick,
Your example will work fine.
I made a mistake in my sentence. I meant not multiple files in namespace
but multiple namespaces in file.
Proposed concept allows multiple files in namespace but not multiple
namespaces in file.
Thanks. Dmitry.
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]
Sent: Monday, July 09, 2007 10:38 PM
To: Dmitry Stogov
Cc: 'Larry Garfield'; internals@lists.php.net
Subject: RE: [PHP-DEV] Simple Namespace Proposal
On Sun, 8 Jul 2007, Dmitry Stogov wrote:
Note that multiple files in namespace won't allow autoloading.
That got me confused a bit. I was wondering whether the
following would
work (with autoload):
In file a/b.php:
?php
namespace a;
class b { }
?
in file a/c.php:
?php
namespace a;
class c { }
?
In file a/d.php:
?php
namespace a;
class d { }
?
in file a/e.php:
?php
namespace a;
class e { }
?
in index.php:
?php
function __autoload( $className )
{
include str_replace( ::, /, $className ) . .php;
}
$b = new a::b;
$c = new a::c;
import a;
$d = new d;
$e = new e;
?
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SPL as non-disablable extension (Was: Re: [PHP-DEV] Simple Namespace Proposal)
On Tue, 10 Jul 2007, Lukas Kahwe Smith wrote: On 10.07.2007, at 00:06, Stanislav Malyshev wrote: I know, and I use spl_autoload_register. But then I would blatantly suggest to remove __autoload() in PHP6 and force SPL to be compiled into PHP. I wouldn't go as far as removing it, but definitely would go as far as not recommending to use it if writing a library or application that includes independent modules (such as libraries). If you application is homogeneous and non-modular, then using it may be ok. Well if we are speaking of best practices, the sensible thing for libs to do is to provide a function/method users can call inside their own __autoload() implementation. This way users are free to make their __autoload() work as they please/require. That's what we're doing... however, I don't mind the force SPL to be compiled into PHP bit. I think we should do that. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
On Mon, 9 Jul 2007, chris# wrote: On Mon, 9 Jul 2007 14:38:03 -0700, Andrei Zmievski [EMAIL PROTECTED] wrote: Yes, backporting major features from PHP 6 to 5 will slow down PHP 6 adoption, and I'd like to avoid it if possible. There is a way to run two engines side by side, by the way: in separate instances of Apache. It's really not that complicated. Isn't there some evidence of the ability to run two engines side-by-side with only one instance of Apache; thereby eliminating some overhead? Wouldn't that actually be easier? I could have sworn I saw that somewhere. You can do that with fastcgi and lighttpd, not with apache. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
On Mon, 9 Jul 2007, Nicolas Bérard-Nault wrote: Permit me to give my 2 cents on that and share my small bit of experience with PHP 6. First of all, I totally agree with you Antony. I'm currently working on deploying a big codebase in PHP 6 (for those of you who didn't know, I'm the GSoC student working on refactoring Jaws for PHP 6) and my head started to ache when I began understanding all the complications of the unicode implementation as it is right now. Basically, having that unicode.semanticsPHP_INI switch just totally kills the fun because I have to have a working application if it is ON or OFF. Why? Just state that it only works when it is turned ON - I am pretty sure that that's the way we'll go. Long story short, this forces me to explicitly define each string as either binary or unicode, which doesn't make any PHP sense. It's actually the first time I'm forced to explicitly specify a variable type in PHP and I'm not sure I'm the only one who's not happy about this. I like the unicode support and really appreciate all the work that's been done on it but I absolutely think it should be implemented without that headache/pain in the ass switch that'll make transition even tougher for everyone. That I agree with :) Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
On Tue, 10 Jul 2007 00:52:27 -0500, Larry Garfield [EMAIL PROTECTED] wrote: On Monday 09 July 2007, chris# wrote: OK. I can't help but notice the overall underwhelming reception to PHP5 (mostly by ISP's). Which begs the question /why/? Shouldn't /that/ be the question? Or maybe I should ask: Has anybody bothered to find out why the majority of PHP installers /prefer/ PHP4? I am quite sure that if those questions were answered, the poll you are attempting to take now would be moot. Don't you? I don't claim to have made a scientific study of the subject, but from what I've seen so far web hosts fall into one of the following categories: 1) We offer PHP 5 only. 2) We offer PHP 5 and PHP 4 as an option if you ask/tweak .htaccess. 3) We offer PHP 4 and PHP 5 as an option if you ask/tweak .htaccess. 4) We offer PHP 4 and PHP 5, and you explicitly pick one when signing up. 5) We don't offer PHP 5 yet because we haven't figured out how to do that in cPanel and we're afraid of breaking stuff. Hello, and thanks for taking the time to respond. I've actually been pleasantly surprised to find that group 5 seems to be a minority. There's a fair number of hosts in groups 3 and 4 that, I think, artificially deflate PHP 5's numbers. That's made developers gun-shy. I have noticed a growing trend to offer both. Frankly, I think that you're correct in #5 being in the (growing) minority. But I believe this is all due to the lack of how-to/documentation for providing a reliable process to run multiple versions of PHP on the same boxen. Truth be known; I spent two entire days searching for a reliable and straight-forward approach to doing just that. The closest thing I discovered in meeting that goal was running two PHP installs in two different directories (PHP4 as base install in default dir: php and PHP5 in same $prefix but in php5 dir) then running php as Apache lib and assigning libphp5.so to PHP5 enabled folder (or extension - .php5) and assigning libphp4.so as default and for .php. This works fine for *BSD because of the way *BSD loads libraries. But not so for most other *NIX like OS's - most notably Linux. So, while this method will work fine for me and my 50+ *BSD server farm. It isn't /even/ a good generic method for the Internet at large. Probably the best solution would be for one of the seasoned developers whom undoubtedly runs more than one version on his/her boxen as a necessity, to share their experience in achieving this working environment. Better still; posting this prominently on the front page of the php.net site (or the documentation page). That way it would eliminate (or nearly) all fear of offering more (or all) versions of PHP, and PHP4 would simply fade away as ppl can more easily migrate to 5, or 6 without giving it a second thought. How are the Nexen stats compiled? Johannes has said that he has statistics showing that PHP 5 has 60% of the market, not 20%. Quoth Ben Franklin, there are likes, damned lies, and statistics. But at this point I don't think the situation is as dire as everyone seems to think. The huge flood of hosts we had signing up with GoPHP5 in the first day, combined with the other hosts I've spoken to, suggest that simple inertia is the problem at this point, not simply no hosts offer it. I would also contend that there is also an incentive to listing their site on your page, as it gives them higher visibility. :) This, of course skews the results. Thanks again for the response. -- Larry GarfieldAIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php / Service provided by hitOmeter.NET internet messaging! . -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: SPL as non-disablable extension (Was: Re: [PHP-DEV] Simple Namespace Proposal)
Well if we are speaking of best practices, the sensible thing for libs to do is to provide a function/method users can call inside their own __autoload() implementation. This way users are free to make their __autoload() work as they please/require. That's OK too, but this requires the user to always implement __autoload. And now what happens if this module is aggregated into other application? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: SPL as non-disablable extension (Was: Re: [PHP-DEV] Simple Namespace Proposal)
On Tue, 10 Jul 2007, Stanislav Malyshev wrote: Well if we are speaking of best practices, the sensible thing for libs to do is to provide a function/method users can call inside their own __autoload() implementation. This way users are free to make their __autoload() work as they please/require. That's OK too, but this requires the user to always implement __autoload. And now what happens if this module is aggregated into other application? The application should define this, not the library or module... Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: SPL as non-disablable extension (Was: Re: [PHP-DEV] Simple Namespace Proposal)
The application should define this, not the library or module... Why not? If library needs to load files, why can't it define how to load them? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
On Tue, 10 Jul 2007 07:02:15 +0200, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: On 10.07.2007, at 01:19, chris# wrote: On Mon, 9 Jul 2007 14:38:03 -0700, Andrei Zmievski [EMAIL PROTECTED] wrote: Yes, backporting major features from PHP 6 to 5 will slow down PHP 6 adoption, and I'd like to avoid it if possible. There is a way to run two engines side by side, by the way: in separate instances of Apache. It's really not that complicated. Isn't there some evidence of the ability to run two engines side-by- side with only one instance of Apache; thereby eliminating some overhead? Wouldn't that actually be easier? I could have sworn I saw that somewhere. maybe someone could make runkit really fast .. *nudge* DOH! I've been using PHP since it was invented and /can/ /not/ believe I didn't see this. I'm looking at it now. Looks intriguing. What's your experience with it? Thanks for the pointer/response! regards, Lukas / Service provided by hitOmeter.NET internet messaging! . -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
On Mon, 9 Jul 2007, Pierre wrote: On 7/9/07, Derick Rethans [EMAIL PROTECTED] wrote: On Fri, 6 Jul 2007, Andi Gutmans wrote: I'd suggest something close to what Rasmus suggested: a) We make a clear statement on PHP.net that at the end of the year we plan to discontinue bug fixes for PHP 4 except for security fixes. b) We will discontinue supporting PHP 4 on 8/8/8 (because it sounds good and gives people about a year). The attached patch mentions the above. As you can see, the idea is to release this on the 13th, 3 years after php 5 was released for this first time. First thanks for the patch! I changed the first two paragraphs to: p Today it is exactly three years ago since PHP 5 has been released. In those three years it has seen many improvements over PHP 4. PHP 5 is fast, stable amp; production-ready and as PHP 6 is on the way, PHP 4 will be discontinued. /p p Hereby the PHP development team announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. In case security issues might arise after this date, we will consider making security-only releases up to 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5. /p I think that reads better. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
On Tue, 10 Jul 2007 00:56:16 -0500, Larry Garfield [EMAIL PROTECTED] wrote: On Monday 09 July 2007, chris# wrote: I will venture to say that the biggest issue was; no transition period. That is to say that PHP4 and PHP5 are two completely different creatures. There was no morphing period. After several years of working with PHP3/4 in this fashion, /suddenly/ most of those rules no longer applied (in PHP5). You've got millions - perhaps billions of lines of code that have to be nearly completely rewritten to be usable in PHP5. Perhaps a better solution would be to document an answer to running PHP4, PHP5, and PHP6 on the same boxen for the most popular OS's. Then there would be little reason for anyone not to adopt any version(s) of their choosing, and little reason to complain about an EOL. Seems a sure answer to me. Better docs on how to run PHP 4 and PHP 5 at the same time would likely be helpful, and someone is working on that for GoPHP5.org, I think. However, your claim that you have millions... of lines of code that have to be nearly completely rewritten to be usable in PHP 5 is not true. Sure, you could completely rewrite your app, but unless you're doing something very very dependent on objects passing by value porting a PHP 4 app to run correctly in PHP 5 is not the herculean task that some make it out to be. You don't /have/ to rewrite everything to use objects. Even the procedural code is easier, with the extra array manipulation routines. :-) That sounds like more of a marketing issue. Greetings, and thanks for the response. For the sake of clarity; I was /not/ indicating that /I/ had millions of lines of code to /completely/ rewrite. But rather that there /are/ millions (perhaps billions) of lines of code that need to be rewritten on the Internet in various applications/ libraries/classes, etc... And for many, this seems quite - as you put it, the herculean task. Remember, most ppl using PHP on their pages depend on others to write their pages/applications/ utilities. They go to sourceforge/freshmeat/phpclasses/hotscripts download something that appeals to them and discover that it don't werk on the PHP5 boxen their ISP/ hosting provider offers. So they discover they need to fix it to make it work. To most - whom know very little about programming in PHP, this is quite a feat. So as most in the world; they take the least-line-of-resistance and find a PHP4 hosting provider. Bottom line; there are zillions of PHP thingies out there that were all written for PHP4 - far more than are available for 5. So until many (most?) of them have been re-written (more accurately; adapted) for PHP5, PHP4 will still be a /big/ contender - like it or not. OH, before I forget to respond; PHP5 is a completely different animal than PHP4 for the average user. Sure. If you were familiar with Java/Script it all looks quite familiar - technically any OO language for that matter. Hell, I've been with PHP since it's creation, coming from years with perl and converting most of my trusty scripts to PHP. I also discovered many ways to write PHP4 as pseudo OO. Like many I suppose. Anyway, speaking of the past; I remember there being quite bit of resistance to the OO flavor that PHP5 offered. Perhaps it lingers still. Well, here's looking forward to feasible solutions to offering multiversions on most PHP hosters. ;) Thanks again for the response. -- Larry GarfieldAIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php / Service provided by hitOmeter.NET internet messaging! . -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
On Tue, 10 Jul 2007 08:39:10 +0200 (CEST), Derick Rethans [EMAIL PROTECTED] wrote: On Mon, 9 Jul 2007, chris# wrote: On Mon, 9 Jul 2007 14:38:03 -0700, Andrei Zmievski [EMAIL PROTECTED] wrote: Yes, backporting major features from PHP 6 to 5 will slow down PHP 6 adoption, and I'd like to avoid it if possible. There is a way to run two engines side by side, by the way: in separate instances of Apache. It's really not that complicated. Isn't there some evidence of the ability to run two engines side-by-side with only one instance of Apache; thereby eliminating some overhead? Wouldn't that actually be easier? I could have sworn I saw that somewhere. You can do that with fastcgi and lighttpd, not with apache. Thanks for taking the time to respond. I don't wish to sound argumentative. But I have discovered; while it won't work with Linux (others?), it does work on *BSD with Apache. The difference is in the way libraries are loaded - DL. I found quite a long article where someone shared their experimentation attempting it. The responses from 100's of others all stated it didn't work for them. The one thing all the failures all had in common was that their OS was some Linux distro. Thanks again for the response. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org / Service provided by hitOmeter.NET internet messaging! . -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
On Tue, 10 Jul 2007 09:34:12 +0200 (CEST), Derick Rethans [EMAIL PROTECTED] wrote: On Mon, 9 Jul 2007, Pierre wrote: On 7/9/07, Derick Rethans [EMAIL PROTECTED] wrote: On Fri, 6 Jul 2007, Andi Gutmans wrote: I'd suggest something close to what Rasmus suggested: a) We make a clear statement on PHP.net that at the end of the year we plan to discontinue bug fixes for PHP 4 except for security fixes. b) We will discontinue supporting PHP 4 on 8/8/8 (because it sounds good and gives people about a year). The attached patch mentions the above. As you can see, the idea is to release this on the 13th, 3 years after php 5 was released for this first time. First thanks for the patch! I changed the first two paragraphs to: No offense, I can't resist... p Today has been exactly three years since PHP 5 was released. In those three years it has seen many improvements over PHP 4. PHP 5 is fast, stable production-ready and as PHP 6 is on the way, PHP 4 will soon be discontinued. /p p As such, the PHP development team announces that support for PHP 4 will continue only until the end of this year. After 2007-12-31 there will be no further releases of PHP 4.4. Except in cases of security issues that may arise. Security-only releases will also terminate on 2008-08-08. We strongly recommend upgrading your applications to PHP 5. /p I think that reads better. I like this even better. ;) Thoughts? Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php / Service provided by hitOmeter.NET internet messaging! . -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
On 7/10/07, Derick Rethans [EMAIL PROTECTED] wrote: You can do that with fastcgi and lighttpd, not with apache. not true. you can do that with ANY server which uses fastcgi (apache can do that too!) actualy, I believe fastcgi-mode should get some advertising from php.net as it really have its advantages -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
On Tue, 10 Jul 2007, Alexey Zakhlestin wrote: On 7/10/07, Derick Rethans [EMAIL PROTECTED] wrote: You can do that with fastcgi and lighttpd, not with apache. not true. you can do that with ANY server which uses fastcgi (apache can do that too!) Actualy, I believe fastcgi-mode should get some advertising from php.net as it really have its advantages You're right - didn't think of that, but then again, it was a sneak commercial for lighttpd ;-) Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
On Tue, Jul 10, 2007 at 01:09:35AM -0700, chris# wrote: No offense, I can't resist... Neither can I: p Today has been exactly three years since PHP 5 was released. In those three years it has seen many improvements over PHP 4. PHP 5 is fast, stable production-ready and as PHP 6 is on the way, PHP 4 s//amp;/ will soon be discontinued. /p p As such, the PHP development team announces that support for PHP 4 will continue only until the end of this year. After 2007-12-31 there will be no further releases of PHP 4.4. Except in cases of security issues that may arise. Security-only releases will also terminate on 2008-08-08. We strongly recommend upgrading your applications to PHP 5. /p -- Alain Williams Linux 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 #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: SPL as non-disablable extension (Was: Re: [PHP-DEV] Simple Namespace Proposal)
Derick Rethans schrieb: That's what we're doing... however, I don't mind the force SPL to be compiled into PHP bit. I think we should do that. Since the manual says This extension is available and compiled by default in PHP 5., so a lot of developers (me included) rely on SPL funtionality nowadays, so not compiling it into PHP in a certain installation is a recipe for diaster that should be avoided. Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: SPL as non-disablable extension (Was: Re: [PHP-DEV] Simple Namespace Proposal)
On 10.07.2007, at 09:17, Stanislav Malyshev wrote: The application should define this, not the library or module... Why not? If library needs to load files, why can't it define how to load them? - the application should define how things get loaded, precisely because it decides about what libraries are used, what approach each of them has taken etc. also on the application level you may want to implement some way to override implementations from the library etc. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
My 2 cents... p As of XX-XX-2007, it will have been 3 years since the release of PHP 5. In these 3 years many improvements have been implemented over PHP 4 and PHP 5 can now be considered fast, stable amp; production ready. With PHP 6 in active development PHP 4 development will now be discontinued. /p p Hereby the PHP development team announces that support for PHP 4 will be discontinued as of 2007-12-31, after this date there will be no more releases of PHP 4.4. Security issue's found in PHP 4.4 after this date will be evaluated for severity and the development team will consider relasing security updates until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5. /p Regards Marco
[PHP-DEV] [PATCH] LDAP module patch (adding new functionality).
Hi, now that there seems to be a maintainer of the LDAP extension (I've cc'ed this message to him), I thought I could try to push this patch again :-) Instead of trying to push my own (limited) patch which only supports pagedResults control extension, I've taken Pierangelo Masarati's patches (PAT18 and PAT19) and have updated them to apply to 5.2.3 cleanly (as of today) and fixed a memory leak. In addition to it, I've added 4 test scripts based on the examples from Pierangelo, with a few modifications by me. I have tested this patch by building PHP with OpenLDAP 2.2.23 libraries (under Debian Sarge) and run the test scripts against both OpenLDAP 2.2.23 slapd server and MS Active Directory (runnning under W2K3 in W2K3 functional mode). OpenLDAP passes all the tests except passwordPolicy control extension (because it doesn't support it) and MS Active Directory passes only the pagedResult test (because it doesn't support the rest of the implemented controls for which tests exist). The patch is available at: http://www.eteo.mondragon.edu/descargas/php-ldap/php-ext-ldap-5.2.3.diff.txt.gz Could you please add this to the next stable PHP release? I badly need pagedResults control extension support in PHP :-) Saludos. Iñaki. -- School of Management Mondragon University 20560 Oñati - Spain +34 943 718009 (ext. 225) GPG Key available at public keyservers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RIP PHP 4?
I wouldn't say consider in releasing security fixes. I would say that we won't make any more releases except in cases of security bugs. Andi -Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 10, 2007 12:34 AM To: Pierre Cc: PHP Developers Mailing List Subject: Re: [PHP-DEV] RIP PHP 4? On Mon, 9 Jul 2007, Pierre wrote: On 7/9/07, Derick Rethans [EMAIL PROTECTED] wrote: On Fri, 6 Jul 2007, Andi Gutmans wrote: I'd suggest something close to what Rasmus suggested: a) We make a clear statement on PHP.net that at the end of the year we plan to discontinue bug fixes for PHP 4 except for security fixes. b) We will discontinue supporting PHP 4 on 8/8/8 (because it sounds good and gives people about a year). The attached patch mentions the above. As you can see, the idea is to release this on the 13th, 3 years after php 5 was released for this first time. First thanks for the patch! I changed the first two paragraphs to: p Today it is exactly three years ago since PHP 5 has been released. In those three years it has seen many improvements over PHP 4. PHP 5 is fast, stable amp; production-ready and as PHP 6 is on the way, PHP 4 will be discontinued. /p p Hereby the PHP development team announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. In case security issues might arise after this date, we will consider making security-only releases up to 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5. /p I think that reads better. Derick -- 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] What is the use of unicode.semantics in PHP 6?
I was thinking a bit more about this yesterday. Even if I'd agree with this discussion (which I don't at this point in time) I think it is being had far too early. We currently have a very big problem with ability to upgrade to PHP 6 and making decisions without people actually getting their feet wet and seeing what the issues are is not a good idea. Purist decisions tend to fail when they meet the real world. What I really think we need to do for this release, which we haven't been good at doing in the past, is build a PHP Compatibility Team which tries to port many applications to PHP 6 and finds the issues in doing this port (both with unicode_semantics=on/off). We can then learn from this experience and have good documentation on how to upgrade to both modes and in some cases, like we have done in the past 2-3 weeks, tweak PHP 6 to not break backwards compatibility. It is possible in many cases. It's something we are willing to spend time on and as I mentioned already started to do but it would really require a larger amount of volunteers to pick various apps and do it. This kind of information would be far more valuable to the project at this point than a prolonged thread about a piece of software which isn't finish (and would also give more information for a discussion like the one we've been having). No one really knows how good/bad of a situation we are at right now. I know from my end it doesn't look great yet. Andi -Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED] Sent: Monday, July 09, 2007 7:39 PM To: Antony Dovgal; Andrei Zmievski Cc: Stas Malyshev; internals@lists.php.net Subject: RE: [PHP-DEV] What is the use of unicode.semantics in PHP 6? The large amount of the dual IS_UNICODE/IS_STRING will need to stay in the code base anyway as we will be supporting binary strings in PHP 6. So it's not accurate that all these maintance issues will be resolved by not supporting unicode_semantics=off. I believe unlike what Andrei said, for a large community of ours (probably the majority) default unicode_semantics=on will not be of interest (we don't live in a purists world). Many won't want to run it because it's going to be significantly slower and will be harder for them to work with. This community will be best served to be able to run in native 8bit mode and having some Unicode functionality available if/when needed. Having dual mode in PHP 6 is not the same as forking two code bases. There is still like namespaces automatically reach both audiences. If we're talking from a pure what is most useful to the majority of our users I'd actually argue that explicit Unicode strings would be the most convenient, i.e. instead of doing b8bitstring you'd do Uunicodestring. Other languages do the same and there are reasons for that. As we've decided on a more aggressive (and risky) approach, I think having this dual mode is extremely important. It will also make the upgrade path easier. Btw, I don't know how many of you have actually tried to port PHP 5 apps to PHP 6 but it's quite a disaster. We made some fixes in the past 2-3 weeks and its getting better but it still requires a lot of work. If we don't make this easy then this is all not worth too much. This project has never been a purists project which is why it's been so successful, let's not start now... Andi -- 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] What is the use of unicode.semantics in PHP 6?
Andi Gutmans wrote: What I really think we need to do for this release, which we haven't been good at doing in the past, is build a PHP Compatibility Team which tries to port many applications to PHP 6 and finds the issues in doing this port (both with unicode_semantics=on/off). We can then learn from this experience and have good documentation on how to upgrade to both modes and in some cases, like we have done in the past 2-3 weeks, tweak PHP 6 to not break backwards compatibility. It is possible in many cases. I'd volunteer for this. Does it help you guys to get started with this today, or should I be waiting till there's more agreement on some of this stuff.. Evert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Creating an object-oriented PHP extension
Hi there, I'm trying to create an object-oriented PHP 5 extension. As I don't know any step-by-step tutorial which would explain everything in detail I'm trying to understand various sources and documents I happen to run into. I'd appreciate if anyone could comment on what I currently think the typical steps look like (the more comments the better as it's a rather random learning process): * Before a class can be used it must be registered with zend_register_internal_class(). The returned pointer is typically saved in a global zend_class_entry* (why I don't know - do you need the pointer somewhere later?). * As you need to register a class before you can use it you must call the code somewhere - a good place is the module startup function. * In order to call zend_register_internal_class() you need another another zend_class_entry first. It can be initialized with INIT_CLASS_ENTRY which sets the class name and assigns the function table (which contains member functions declared with PHP_ME). * Classes are instantiated by calling the function assigned to zend_class_entry::create_object. Thus apart from the initializiation with INIT_CLASS_ENTRY zend_class_entry::create_object must be set in the module startup function. * In the create_object function a zend_object is created and initialized (with zend_object_std_init). Furthermore the default_properties of the class are copied to the properties of the zend_object (with zend_hash_copy). Default properties need to be added to zend_class_entry* after the class is registered in the module startup function (with one of the many add_property_... functions). * As the create_object function does not return the newly created zend_object directly it must be stored in a zend_object_handle together with function pointers to a destructor, free storage function and storage clone function (is this a copy constructor if you use C++ terminology?). The function zend_objects_store_put() can be used to do all of this. * The zend_object_handle returned by the create_object function needs also a pointer to zend_object_handlers. This is a hash table which contains various object handlers - among others functions to read/write properties. The object handlers object is typically created and initialized in the module startup function (as it is the same for all objects of the same class). Is there any overview what these object handlers are used for and when exactly you should define your own? I especially wonder what the read/write property handlers are good for as you define properties in the class? They don't seem to be unimportant though as I've seen dozens of them in the DOM extension for example. Boris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: SPL as non-disablable extension (Was: Re: [PHP-DEV] Simple Namespace Proposal)
the application should define how things get loaded, precisely because it decides about what libraries are used, what approach each of them has taken etc. also on the application level you may want to implement some way to override implementations from the library etc. Why application developer should even care how library is build internally, let alone override it's loading behavior? These are exactly the implementation details that should be hidden from the library user. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: SPL as non-disablable extension (Was: Re: [PHP-DEV] Simple Namespace Proposal)
On 10.07.2007, at 18:55, Stanislav Malyshev wrote: the application should define how things get loaded, precisely because it decides about what libraries are used, what approach each of them has taken etc. also on the application level you may want to implement some way to override implementations from the library etc. Why application developer should even care how library is build internally, let alone override it's loading behavior? These are exactly the implementation details that should be hidden from the library user. because someone needs to decide in what order autoload strategies are applied. this is especially important for libraries that do not prefix their class names yet. and like i said its also important to be able to easily replace a class from a library without having to muck around with the installed files themselves. if you are recommending libraries to do all of this themselves, you are handing a recipe for desaster. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
On Mon, 2007-07-09 at 19:38 -0700, Andi Gutmans wrote: Btw, I don't know how many of you have actually tried to port PHP 5 apps to PHP 6 but it's quite a disaster. We made some fixes in the past 2-3 weeks and its getting better but it still requires a lot of work. If we don't make this easy then this is all not worth too much. I'd prefer if we would fix the failing tests with make test first. These tests already show some problems we might have which might require some general improvement. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Creating an object-oriented PHP extension
Hi Boris, On Tue, 2007-07-10 at 15:38 +0200, Boris wrote: Hi there, I'm trying to create an object-oriented PHP 5 extension. As I don't know any step-by-step tutorial which would explain everything in detail I'm trying to understand various sources and documents I happen to run into. I'd appreciate if anyone could comment on what I currently think the typical steps look like (the more comments the better as it's a rather random learning process): Well there's Sara's book (SBN-10: 067232704X or ISBN-13: 978-0672327049) and there are Marcus Code Camp slides (while slides without the talk don't work the same) which show all the things step by step. * Before a class can be used it must be registered with zend_register_internal_class(). The returned pointer is typically saved in a global zend_class_entry* (why I don't know - do you need the pointer somewhere later?). Yes, you need the ce everywhere, where you want to reference that class (checking whether an object passed to to you is of the correct type, checking properties, etc.) * As you need to register a class before you can use it you must call the code somewhere - a good place is the module startup function. It is the best place. * In order to call zend_register_internal_class() you need another another zend_class_entry first. It can be initialized with INIT_CLASS_ENTRY which sets the class name and assigns the function table (which contains member functions declared with PHP_ME). Right, first setup everything on your ce then give it to the engine which makes a copy for further use. * Classes are instantiated by calling the function assigned to zend_class_entry::create_object. Thus apart from the initializiation with INIT_CLASS_ENTRY zend_class_entry::create_object must be set in the module startup function. An class might work without your own create_object handler, but usually you want to store additional data (like pointers to some complex data structure) inside your object so you have to allocate and initilise that. * In the create_object function a zend_object is created and initialized (with zend_object_std_init). Furthermore the default_properties of the class are copied to the properties of the zend_object (with zend_hash_copy). Default properties need to be added to zend_class_entry* after the class is registered in the module startup function (with one of the many add_property_... functions). yes * As the create_object function does not return the newly created zend_object directly it must be stored in a zend_object_handle together with function pointers to a destructor, free storage function and storage clone function (is this a copy constructor if you use C++ terminology?). The function zend_objects_store_put() can be used to do all of this. Objects are registered in the object storage, where they live and are referenced by zvals (php variables) * The zend_object_handle returned by the create_object function needs also a pointer to zend_object_handlers. This is a hash table which contains various object handlers - among others functions to read/write properties. The object handlers object is typically created and initialized in the module startup function (as it is the same for all objects of the same class). Is there any overview what these object handlers are used for and when exactly you should define your own? I especially wonder what the read/write property handlers are good for as you define properties in the class? They don't seem to be unimportant though as I've seen dozens of them in the DOM extension for example. There's a file Zend/OBJECTS2_HOWTO or similar which should list all handlers. read/write property handlers act similar to __get/__set in userland, you can overwrite them if you don't want to use regular properties but directly modify stuff in your internal structures or offer read-only properties. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suggestion for fixing Bug #40928
/en-us/ntcmds_shelloverview.mspx?mfr=true , quoting: You can use most characters as variable values, including white space. If you use the special characters , , |, , or ^, you must precede them with the escape character (^) or quotation marks. - So all special characters will be replaced with ^char. I think you are not entirely correct here. What the quote means is that if you want foobar, you should do either foobar or foo^bar - not replace with ^. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Always enable mail() function
Hi,
recently I had the problem that we disable the mail() function if
configure can't find the sendmail binary. Is there any real reason for
this? I can image a few situations where the binary is in a non-standard
location or PHP is compiled on a different host than used.
I'd like to commit the attached patch which should always enable mail(),
any objections?
johannes
P.S. If it doesn't come through: The patch is available on
http://schlueters.de/~johannes/php/php_mail_always_available.diff too.
Index: ext/mbstring/mbstring.c
===
RCS file: /repository/php-src/ext/mbstring/mbstring.c,v
retrieving revision 1.268
diff -u -p -r1.268 mbstring.c
--- ext/mbstring/mbstring.c 4 Apr 2007 15:23:09 - 1.268
+++ ext/mbstring/mbstring.c 10 Jul 2007 21:16:22 -
@@ -3317,7 +3317,6 @@ PHP_FUNCTION(mb_decode_numericentity)
/* {{{ proto int mb_send_mail(string to, string subject, string message [, string additional_headers [, string additional_parameters]])
* Sends an email message with MIME scheme
*/
-#if HAVE_SENDMAIL
#define SKIP_LONG_HEADER_SEP_MBSTRING(str, pos) \
if (str[pos] == '\r' str[pos + 1] == '\n' (str[pos + 2] == ' ' || str[pos + 2] == '\t')) { \
@@ -3821,16 +3820,6 @@ PHP_FUNCTION(mb_send_mail)
#undef PHP_MBSTR_MAIL_MIME_HEADER2
#undef PHP_MBSTR_MAIL_MIME_HEADER3
#undef PHP_MBSTR_MAIL_MIME_HEADER4
-
-#else /* HAVE_SENDMAIL */
-
-PHP_FUNCTION(mb_send_mail)
-{
- RETURN_FALSE;
-}
-
-#endif /* HAVE_SENDMAIL */
-
/* }}} */
/* {{{ proto mixed mb_get_info([string type])
Index: ext/standard/basic_functions.c
===
RCS file: /repository/php-src/ext/standard/basic_functions.c,v
retrieving revision 1.862
diff -u -p -r1.862 basic_functions.c
--- ext/standard/basic_functions.c 3 Jul 2007 10:22:55 - 1.862
+++ ext/standard/basic_functions.c 10 Jul 2007 21:16:23 -
@@ -1816,7 +1816,6 @@ ZEND_END_ARG_INFO()
#endif
/* }}} */
/* {{{ mail.c */
-#ifdef HAVE_SENDMAIL
static
ZEND_BEGIN_ARG_INFO(arginfo_ezmlm_hash, 0)
ZEND_ARG_INFO(0, addr)
@@ -1830,7 +1829,6 @@ ZEND_BEGIN_ARG_INFO_EX(arginfo_mail, 0,
ZEND_ARG_INFO(0, additional_headers)
ZEND_ARG_INFO(0, additional_parameters)
ZEND_END_ARG_INFO()
-#endif
/* }}} */
/* {{{ math.c */
static
@@ -3693,10 +3691,8 @@ zend_function_entry basic_functions[] =
PHP_FALIAS(diskfreespace, disk_free_space, arginfo_disk_free_space)
/* functions from mail.c */
-#ifdef HAVE_SENDMAIL
PHP_FE(mail, arginfo_mail)
PHP_FE(ezmlm_hash, arginfo_ezmlm_hash)
-#endif
/* functions from syslog.c */
#ifdef HAVE_SYSLOG_H
@@ -4944,14 +4940,9 @@ PHPAPI int _php_error_log(int opt_err, c
case 1: /*send an email */
{
-#if HAVE_SENDMAIL
if (!php_mail(opt, PHP error_log message, message, headers, NULL TSRMLS_CC)) {
return FAILURE;
}
-#else
-php_error_docref(NULL TSRMLS_CC, E_WARNING, Mail option not available!);
-return FAILURE;
-#endif
}
break;
Index: ext/standard/mail.c
===
RCS file: /repository/php-src/ext/standard/mail.c,v
retrieving revision 1.93
diff -u -p -r1.93 mail.c
--- ext/standard/mail.c 10 Jul 2007 20:23:26 - 1.93
+++ ext/standard/mail.c 10 Jul 2007 21:16:23 -
@@ -35,7 +35,6 @@
#include php_ini.h
#include exec.h
-#if HAVE_SENDMAIL
#ifdef PHP_WIN32
#include win32/sendmail.h
#endif
@@ -271,13 +270,6 @@ PHP_MINFO_FUNCTION(mail)
}
/* }}} */
-#else
-
-PHP_FUNCTION(mail) {}
-PHP_MINFO_FUNCTION(mail) {}
-
-#endif
-
/*
* Local variables:
* tab-width: 4
Index: ext/standard/php_mail.h
===
RCS file: /repository/php-src/ext/standard/php_mail.h,v
retrieving revision 1.20
diff -u -p -r1.20 php_mail.h
--- ext/standard/php_mail.h 1 Jan 2007 09:29:32 - 1.20
+++ ext/standard/php_mail.h 10 Jul 2007 21:16:23 -
@@ -24,11 +24,7 @@
PHP_FUNCTION(mail);
PHP_MINFO_FUNCTION(mail);
-#if HAVE_SENDMAIL
-
PHP_FUNCTION(ezmlm_hash);
PHPAPI extern int php_mail(char *to, char *subject, char *message, char *headers, char *extra_cmd TSRMLS_DC);
-#endif
-
#endif /* PHP_MAIL_H */
Index: main/main.c
===
RCS file: /repository/php-src/main/main.c,v
retrieving revision 1.734
diff -u -p -r1.734 main.c
--- main/main.c 10 Jul 2007 18:42:01 - 1.734
+++ main/main.c 10 Jul 2007 21:16:23 -
@@ -341,7 +341,7 @@ static PHP_INI_MH(OnUpdateDefaultMimetyp
#if defined(PHP_PROG_SENDMAIL) !defined(NETWARE)
# define DEFAULT_SENDMAIL_PATH PHP_PROG_SENDMAIL -t -i
#else
-# define DEFAULT_SENDMAIL_PATH NULL
+# define DEFAULT_SENDMAIL_PATH /usr/sbin/sendmail -t -i
#endif
/* {{{ PHP_INI
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Always enable mail() function
So what happens when sendmail really does not exist? --Jani Johannes Schlüter kirjoitti: Hi, recently I had the problem that we disable the mail() function if configure can't find the sendmail binary. Is there any real reason for this? I can image a few situations where the binary is in a non-standard location or PHP is compiled on a different host than used. I'd like to commit the attached patch which should always enable mail(), any objections? johannes P.S. If it doesn't come through: The patch is available on http://schlueters.de/~johannes/php/php_mail_always_available.diff too. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
I think the sooner the better as it's valuable information for the dev team. It'd probably be a good idea to have a Wiki where we can document issues that/common use-cases which are encountered. Maybe we should have a Wiki on one of the php.net servers for such purposes? Andi -Original Message- From: Evert | Rooftop [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 10, 2007 9:40 AM To: Andi Gutmans Cc: Antony Dovgal; Andrei Zmievski; Stas Malyshev; internals@lists.php.net Subject: Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6? Andi Gutmans wrote: What I really think we need to do for this release, which we haven't been good at doing in the past, is build a PHP Compatibility Team which tries to port many applications to PHP 6 and finds the issues in doing this port (both with unicode_semantics=on/off). We can then learn from this experience and have good documentation on how to upgrade to both modes and in some cases, like we have done in the past 2-3 weeks, tweak PHP 6 to not break backwards compatibility. It is possible in many cases. I'd volunteer for this. Does it help you guys to get started with this today, or should I be waiting till there's more agreement on some of this stuff.. Evert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Always enable mail() function
On Wed, 2007-07-11 at 00:49 +0300, Jani Taskinen wrote: So what happens when sendmail really does not exist? The same as if you configure sendmail_oath wrong or move you binary to a host where it is missing: mail() returns false. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Always enable mail() function
The same as if you configure sendmail_oath wrong or move you binary to a host where it is missing: mail() returns false. I think it's a correct approach - the fact that sendmail wasn't installed (or installed incorrectly maybe) on build machine shouldn't prevent PHP from sending mail of production machine. If production machine doesn't have sendmail - mail() would fail as would any other function, such as database connection, when environment is not set up correctly. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
On Monday 09 July 2007, Stanislav Malyshev wrote: Do _I_ like that horrible IS_STRING/IS_UNICODE mess we have atm? No. I don't think there's any way of having both unstructured character data and Unicode text represented without having two distinct types. Either that or you'd have to tell on each step which one it is, and that would suck much more. I would love to have clean and easy PHP6 without all the compatibility, which creates gazillion problems to both users and developers. Fixing unicode=on does not remove the IS_STRING/IS_UNICODE duality. We still have two kinds of data - unstructured bit stream and structured text. If we want strlen(превед) to return 6 - since that Russian word has 6 characters - then we have no way but recognize that it's not just a collection of bits but Unicode text, and that would require separate type, as I see it. And as I see it, this is the source of the problems when people try to operate on text as on bit stream and vice versa. Unless I totally missed what mess you are referring to... I am coming into this discussion decidedly late here, so please thwap me gently if this is a FAQ. Do we have any idea of what percentage of strings in the wild would break if treated as Unicode vs. not? If 90% of the strings in use would work fine if treated as unicode, then it would make sense to just always assume Unicode unless explicitly specified otherwise. If 90% of the strings in use would die if treated as Unicode, then Unicode should probably be the exception and only when explicitly defined. I'm not liking the ghosts of magic_quotes I'm seeing implied here with different modes for the server to be in. That sounds like it would make writing code that works the same everywhere and is not ugly to read (crapload of markers or lots of conditionals) quite difficult. As I said, feel free to assuage my fear if appropriate. :-) -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
On Tuesday 10 July 2007, chris# wrote: Better docs on how to run PHP 4 and PHP 5 at the same time would likely be helpful, and someone is working on that for GoPHP5.org, I think. However, your claim that you have millions... of lines of code that have to be nearly completely rewritten to be usable in PHP 5 is not true. Sure, you could completely rewrite your app, but unless you're doing something very very dependent on objects passing by value porting a PHP 4 app to run correctly in PHP 5 is not the herculean task that some make it out to be. You don't /have/ to rewrite everything to use objects. Even the procedural code is easier, with the extra array manipulation routines. :-) That sounds like more of a marketing issue. Greetings, and thanks for the response. For the sake of clarity; I was /not/ indicating that /I/ had millions of lines of code to /completely/ rewrite. But rather that there /are/ millions (perhaps billions) of lines of code that need to be rewritten on the Internet in various applications/ libraries/classes, etc... Yes, I understood that you mean there exists millions, perhaps billions of lines. However, I disagree with you on that point. :-) The only way that's possible, IMO, is if you're counting every installed copy of WordPress or Joomla or Drupal or PHPBB or whatever separately. And of course, most of the widely-installed OSS apps are already quite happy on PHP 5, even if they don't leverage its full potential. And for many, this seems quite - as you put it, the herculean task. Remember, most ppl using PHP on their pages depend on others to write their pages/applications/ utilities. They go to sourceforge/freshmeat/phpclasses/hotscripts download something that appeals to them and discover that it don't werk on the PHP5 boxen their ISP/ hosting provider offers. So they discover they need to fix it to make it work. To most - whom know very little about programming in PHP, this is quite a feat. So as most in the world; they take the least-line-of-resistance and find a PHP4 hosting provider. Honestly, it's 2007. Any PHP apps that are not yet compatible with PHP 5 at all are either (1) internal apps that exist once and never leave the server they're on or (2) abandoned. Someone could still be writing code for them, but if the developer hasn't even addressed PHP 5 compatibility yet then the application is abandoned. Users of the application at this point should be looking for a replacement app anyway, independent of anything we do. Bottom line; there are zillions of PHP thingies out there that were all written for PHP4 - far more than are available for 5. So until many (most?) of them have been re-written (more accurately; adapted) for PHP5, PHP4 will still be a /big/ contender - like it or not. See above. By this point they've all been adapted or abandoned. Adapting may be herculean for your average web surfer, but they're not the target audience. The target market is PHP developers (for whom it is not herculean) or server admins (who, from what I've seen, are already moving to PHP 5 even if the stats end up skewed). OH, before I forget to respond; PHP5 is a completely different animal than PHP4 for the average user. Sure. If you were familiar with Java/Script it all looks quite familiar - technically any OO language for that matter. Hell, I've been with PHP since it's creation, coming from years with perl and converting most of my trusty scripts to PHP. I also discovered many ways to write PHP4 as pseudo OO. Like many I suppose. Anyway, speaking of the past; I remember there being quite bit of resistance to the OO flavor that PHP5 offered. Perhaps it lingers still. Well, here's looking forward to feasible solutions to offering multiversions on most PHP hosters. ;) There's still a lot of resistance to OO. There probably always will be, regardless of language. There's nothing wrong with that. It's just one tool and style among many. (Now, if we can get true functional programming ability in PHP as well, then watch the fur fly! g) And that's why it's also a red-herring. One can write perfectly capable, perfectly good PHP 5 without ever using the class keyword. The claim that is still repeated that one has to rewrite everything to be OO in order to port to PHP 5 is, quite simply, FUD. Oh yes, and there is no such thing as Java/Script. Java is a pure-OO language. Javascript is a semi-functional prototype language. The only things they have in common are their first four letters. :-) Thanks again for the response. Cheers. -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it
Re: [PHP-DEV] Always enable mail() function
On 7/10/07, Johannes Schlüter [EMAIL PROTECTED] wrote: Hi, recently I had the problem that we disable the mail() function if configure can't find the sendmail binary. Is there any real reason for this? I suspect there is no real reason, I have always wondered why is like that. I can image a few situations where the binary is in a non-standard location or PHP is compiled on a different host than used. you use sendmail_path in that case ;) http://schlueters.de/~johannes/php/php_mail_always_available.diff too. +1
Re: [PHP-DEV] RIP PHP 4?
On Tue, 10 Jul 2007 19:30:26 -0500, Larry Garfield [EMAIL PROTECTED] wrote: On Tuesday 10 July 2007, chris# wrote: Better docs on how to run PHP 4 and PHP 5 at the same time would likely be helpful, and someone is working on that for GoPHP5.org, I think. However, your claim that you have millions... of lines of code that have to be nearly completely rewritten to be usable in PHP 5 is not true. Sure, you could completely rewrite your app, but unless you're doing something very very dependent on objects passing by value porting a PHP 4 app to run correctly in PHP 5 is not the herculean task that some make it out to be. You don't /have/ to rewrite everything to use objects. Even the procedural code is easier, with the extra array manipulation routines. :-) That sounds like more of a marketing issue. Greetings, and thanks for the response. For the sake of clarity; I was /not/ indicating that /I/ had millions of lines of code to /completely/ rewrite. But rather that there /are/ millions (perhaps billions) of lines of code that need to be rewritten on the Internet in various applications/ libraries/classes, etc... Yes, I understood that you mean there exists millions, perhaps billions of lines. However, I disagree with you on that point. :-) The only way that's possible, IMO, is if you're counting every installed copy of WordPress or Joomla or Drupal or PHPBB or whatever separately. And of course, most of the widely-installed OSS apps are already quite happy on PHP 5, even if they don't leverage its full potential. Fair enough. I have to admit, I had been up for too many hours when seeing your response, and jumped on a reply w/o giving the answer adequate thought - see; reactive. ;) I'll meet you somewhere in the middle on this one. :) And for many, this seems quite - as you put it, the herculean task. Remember, most ppl using PHP on their pages depend on others to write their pages/applications/ utilities. They go to sourceforge/freshmeat/phpclasses/hotscripts download something that appeals to them and discover that it don't werk on the PHP5 boxen their ISP/ hosting provider offers. So they discover they need to fix it to make it work. To most - whom know very little about programming in PHP, this is quite a feat. So as most in the world; they take the least-line-of-resistance and find a PHP4 hosting provider. Honestly, it's 2007. Actually half way to '08 ;) Any PHP apps that are not yet compatible with PHP 5 at all are either (1) internal apps that exist once and never leave the server they're on or (2) abandoned. Now, who's overstating? Someone could still be writing code for them, but if the developer hasn't even addressed PHP 5 compatibility yet then the application is abandoned. Again, an overstatement. But I'll venture to respond... You're overall response presupposes that everyone feels the same about PHP5 as you do - embraces it. This however, is naïeve. As PHP4 still has the largest install base. NOTE: Before anyone starts labeling/accusing me as a PHP5 hater. Let me set the record straight right now: I love /each/ version for different reasons, and will be forever grateful to the developers for it's inception/creation and continued development. I Hope this is now clear. /NOTE Users of the application at this point should be looking for a replacement app anyway, independent of anything we do. Assuming that they have any intention of moving to 5. Is it not also possible that they are hoping for a solution that gives them a bridge from 4 to 5? Or hoping that 6 will fall somewhere between 4 5 - providing the best of both worlds? Given that they all know that PHP Co. knows most of the PHP users aren't flocking to 5. Remember the saying; ppl will most generally always take the least line of resistance. :) Bottom line; there are zillions of PHP thingies out there that were all written for PHP4 - far more than are available for 5. So until many (most?) of them have been re-written (more accurately; adapted) for PHP5, PHP4 will still be a /big/ contender - like it or not. See above. By this point they've all been adapted or abandoned. Adapting may be herculean for your average web surfer, but they're not the target audience. The target market is PHP developers (for whom it is not herculean) or server admins (who, from what I've seen, are already moving to PHP 5 even if the stats end up skewed). Sure. I'll go with you where many developers are concerned. But as Admins go; I'm not convinced that they possess the same savvy that PHP developers do. Their skills are more centered around scripting, and proc management. Which is far more perl oriented that PHP - if either. It's usually bash/sh or rc (again bash/sh). Indeed. They have knowledge of PHP. But more in a general sense, than profound. OH, before I forget to respond; PHP5 is a completely different animal than PHP4 for the average user.
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
Andi Gutmans wrote: I think the sooner the better as it's valuable information for the dev team. It'd probably be a good idea to have a Wiki where we can document issues that/common use-cases which are encountered. Maybe we should have a Wiki on one of the php.net servers for such purposes? Andi Is anyone aware of a list with a, say top 10 PHP applications? When such a wiki is setup, how would you suggest to write such documents.. At least a generic guide would be good (e.g.: common pitfalls) Should I be documenting the per-project specifics as well? Evert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
On Tue, 10 Jul 2007 20:55:30 -0400, Evert | Rooftop [EMAIL PROTECTED] wrote: Andi Gutmans wrote: I think the sooner the better as it's valuable information for the dev team. It'd probably be a good idea to have a Wiki where we can document issues that/common use-cases which are encountered. Maybe we should have a Wiki on one of the php.net servers for such purposes? Andi Is anyone aware of a list with a, say top 10 PHP applications? FWIW I spent quite a bit of time trying to find the best WIKI and found DokuWiki - http://wiki.splitbrain.org/wiki:dokuwiki To be the best in all areas. Really easy to setup and maintain too. Just thought I'd pass it along. When such a wiki is setup, how would you suggest to write such documents.. At least a generic guide would be good (e.g.: common pitfalls) Should I be documenting the per-project specifics as well? Evert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php / Service provided by hitOmeter.NET internet messaging! . -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
On Tuesday 10 July 2007, Evert | Rooftop wrote: Andi Gutmans wrote: I think the sooner the better as it's valuable information for the dev team. It'd probably be a good idea to have a Wiki where we can document issues that/common use-cases which are encountered. Maybe we should have a Wiki on one of the php.net servers for such purposes? Andi Is anyone aware of a list with a, say top 10 PHP applications? When such a wiki is setup, how would you suggest to write such documents.. At least a generic guide would be good (e.g.: common pitfalls) Should I be documenting the per-project specifics as well? Evert Top 10 by what metric? If I had to guess based on market share, I'd say (unordered): Drupal Squirrelmail WordPress phpMyAdmin MediaWiki Joomla PHPBB And I run out of steam here. :-) That's just my guess, though. Probably a better place to look would be to see what is commonly pre-installable or pre-installed at shared hosts. phpMyAdmin and Squirrelmail seem to be everywhere. WordPress, Drupal, Joomla, and PHPBB seem to turn up in free scripts! lists a lot. -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
Larry Garfield wrote: Top 10 by what metric? If I had to guess based on market share, I'd say (unordered): Drupal Squirrelmail WordPress phpMyAdmin MediaWiki Joomla PHPBB That will keep me busy =) Evert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
One final question.. should I assume while converting code unicode.semantics is on or off? If its on I would be making sure everything is properly casted to binary strings where this is needed, if it's off the focus would be on making sure the application runs on both PHP5 and PHP6.. What makes the most sense here? I would personally say I would try it assuming its off, as this is the most likely for the development teams to target for .. Evert Andi Gutmans wrote: I think the sooner the better as it's valuable information for the dev team. It'd probably be a good idea to have a Wiki where we can document issues that/common use-cases which are encountered. Maybe we should have a Wiki on one of the php.net servers for such purposes? Andi -Original Message- From: Evert | Rooftop [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 10, 2007 9:40 AM To: Andi Gutmans Cc: Antony Dovgal; Andrei Zmievski; Stas Malyshev; internals@lists.php.net Subject: Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6? Andi Gutmans wrote: What I really think we need to do for this release, which we haven't been good at doing in the past, is build a PHP Compatibility Team which tries to port many applications to PHP 6 and finds the issues in doing this port (both with unicode_semantics=on/off). We can then learn from this experience and have good documentation on how to upgrade to both modes and in some cases, like we have done in the past 2-3 weeks, tweak PHP 6 to not break backwards compatibility. It is possible in many cases. I'd volunteer for this. Does it help you guys to get started with this today, or should I be waiting till there's more agreement on some of this stuff.. Evert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
