[PHP-DEV] Please reconsider supporting PHP 5.2

2010-07-25 Thread Karoly Negyesi
Hi,

A mere year after releasing Version 5.3.0 (Version 5.3.0 30-June-2009)
you are dropping PHP 5.2 support.

This is a very interesting decision as 5.3.0, compatibility wise, is a
major release. I always felt it was PHP 6.0 but it was not called so
because there was a development branched called that (which was later
abandoned).

Serious BC breaking changes include

Where previously the function would accept the by-value argument, a
fatal error is now emitted.

This broke Drupal 6 big time and while core has been fixed, contrib is
a bit slower to adapt. Previously, it was possible to pass in simply
NULL if you did not care about the by-reference argument.

Also, the deprecation of ereg will affect Drupal 6 over its lifetime
as the module install / enable functionality uses ereg in a way that
can't be fixed: as it is not on a performance critical code path noone
bothered to rewrite the truly ancient directory scanning function
which takes an ereg as it's argument earlier. And we can't break APIs
in a minor release so this can only change in Drupal 7 which is poised
to be released in a few months.

CakePHP had problems with PHP 5.3
http://i.justrealized.com/2009/08/16/cakephp-php-deprecated-error-warning/
and while I am not sure whether these problems got fixed or not, one
year is not a lot of time and so anyone happening to use older CakePHP
for whatever reasons is toast.

Joomla had its share of problems
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdittracker_item_id=17150
but they are fixed now, yes. I can repeat what I said about forcing
new versions.

Then there is the date_default_timezone_set / date.timezone snafu.

While as a Drupal core developer I am _so eager_ to use closures
finally I can't really endorse forcing everyone to switch to another
major version a mere two years after EOLing PHP4. That's fast... too
fast.

Kind regards

Karoly Negyesi

Disclaimer: this email only reflects my own personal opinion. Even if that.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Please reconsider supporting PHP 5.2

2010-07-25 Thread Pierre Joye
hi,

On Sun, Jul 25, 2010 at 11:17 AM, Karoly Negyesi kar...@negyesi.net wrote:
 Hi,

 A mere year after releasing Version 5.3.0 (Version 5.3.0 30-June-2009)
 you are dropping PHP 5.2 support.

We still support 5.2.

There is a huge misunderstanding of end of active support. It means
that only critical bugs (security related) will be fixed in 5.2. It
does not mean that 5.2 is not supported anymore.

 This is a very interesting decision as 5.3.0, compatibility wise, is a
 major release. I always felt it was PHP 6.0 but it was not called so
 because there was a development branched called that (which was later
 abandoned).

 Serious BC breaking changes include

 Where previously the function would accept the by-value argument, a
 fatal error is now emitted.

Not sure about this one. Do you have an example please?

The BC breaks are listed here (required changes due to bugs or bad behaviors) :

http://php.net/manual/en/migration53.php

 Also, the deprecation of ereg will affect Drupal 6


Deprecation is only a message when and only when the error reporting
level is set to display deprecation messages. The deprecated functions
still work as before. Please see http://www.php.net/error_reporting

 Then there is the date_default_timezone_set / date.timezone snafu.

It is now required as nobody read the manual. Without it you simply
expect date/time features to work correctly while relying on random
timezone or none at all.

 While as a Drupal core developer I am _so eager_ to use closures
 finally I can't really endorse forcing everyone to switch to another
 major version a mere two years after EOLing PHP4. That's fast... too
 fast.

5 years is not too fast. Also again, it is not EOL. Distributions will
also take care of back porting what they have to for their releases
lifetime. But we can't. We don't have the resource nor the time to
maintain minor releases for 10 years. It is also important to notice
that clean code running well with 5.2 will run just as fine with 5.3
as well (yes, clean is all relative but I hope you understand my point
:).

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] Re: Please reconsider supporting PHP 5.2

2010-07-25 Thread Karoly Negyesi
 Where previously the function would accept the by-value argument, a
 fatal error is now emitted.

 Not sure about this one. Do you have an example please?

Erm, you do realized that I copied that from the handbook page? Example:

?php
function a($x) {}
a(NULL);
?
PHP Fatal error:  Only variables can be passed by reference in
/var/www/u/sites/all/modules/awesomerelationships/x.php on line 4

Also.

Extensions. APC to this day does not have a stable release for PHP
5.3. Neither has XCache. I am not even sure how do you imagine
*anyone* much less everyone upgrading to 5.3 with a production site
without a stable code cache...?

Also note xdebug has a PHP 5.3 compatible release for less than a month.

Regards

NK

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] Re: Please reconsider supporting PHP 5.2

2010-07-25 Thread Karoly Negyesi
 Extensions. APC to this day does not have a stable release for PHP
 5.3. Neither has XCache. I am not even sure how do you imagine
 *anyone* much less everyone upgrading to 5.3 with a production site
 without a stable code cache...?

Sorry, apparently XCache 1.3 version does work with 5.3 it's only the
homepage of it that does not mention this :)

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Please reconsider supporting PHP 5.2

2010-07-25 Thread Pierre Joye
hi,

On Sun, Jul 25, 2010 at 11:44 AM, Karoly Negyesi kar...@negyesi.net wrote:
 Where previously the function would accept the by-value argument, a
 fatal error is now emitted.

 Not sure about this one. Do you have an example please?

 Erm, you do realized that I copied that from the handbook page? Example:

No, as you did not show any code and I was not sure what you meant
exactly. Thanks to have clarified this case.

 Also.

It is not the EOL for 5.2.

Cheers,
-- 
Pierre

@pierrejoye | 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] Re: Please reconsider supporting PHP 5.2

2010-07-25 Thread Reindl Harald
Am 25.07.2010 11:44, schrieb Karoly Negyesi:
 Where previously the function would accept the by-value argument, a
 fatal error is now emitted.
 
 Not sure about this one. Do you have an example please?
 
 Erm, you do realized that I copied that from the handbook page? Example:
 
 ?php
 function a($x) {}
 a(NULL);
 ?
 PHP Fatal error:  Only variables can be passed by reference in
 /var/www/u/sites/all/modules/awesomerelationships/x.php on line 4

Thanks god that tis happens to force developers to work clean
NULL is not a reference so th real error os that such things
ever worked

 Extensions. APC to this day does not have a stable release for PHP
 5.3. Neither has XCache. I am not even sure how do you imagine
 *anyone* much less everyone upgrading to 5.3 with a production site
 without a stable code cache...?

That is not a php-problem and http://eaccelerator.net/ works

 Also note xdebug has a PHP 5.3 compatible release for less than a month.

the question is not how long, the question is does it have

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Please reconsider supporting PHP 5.2

2010-07-25 Thread Reindl Harald

Am 25.07.2010 11:17, schrieb Karoly Negyesi:

 This is a very interesting decision as 5.3.0, compatibility wise, is a
 major release. I always felt it was PHP 6.0 but it was not called so
 because there was a development branched called that (which was later
 abandoned).

This is simply not true

A clean designed application has to run the whole time with
error_reporting = E_ALL | E_STRICT and so you should have seen
the problems long ago

 This broke Drupal 6 big time and while core has been fixed, contrib is
 a bit slower to adapt. Previously, it was possible to pass in simply
 NULL if you did not care about the by-reference argument.

The problem is that the developers of drupal, joomla, wordpress
are not working error_reporting = E_ALL | E_STRICT as i do since
teh first day i use php even on production servers

While 122 installations of our own software throwing up to 10
warnings a month many other software rides a DOS-attack against mysql
if rsyslog is using a database

 Also, the deprecation of ereg will affect Drupal 6 over its lifetime
 as the module install / enable functionality uses ereg in a way that
 can't be fixed: as it is not on a performance critical code path noone
 bothered to rewrite the truly ancient directory scanning function
 which takes an ereg as it's argument earlier. And we can't break APIs
 in a minor release so this can only change in Drupal 7 which is poised
 to be released in a few months.

Seems that you do not understand what deprecated means?
See that such calls are using a @ before to not make crazy
peopole like me with thousands of warnings and you have time
enough to clean your code

 Then there is the date_default_timezone_set / date.timezone snafu.

If this is a problem the sysadmin did not his job
date.timezone = Europe/Vienna in php.ini exists
since years an dshould be set in all clan server setups



signature.asc
Description: OpenPGP digital signature


[PHP-DEV] Karoly Negyesi: What do you really want?

2010-07-25 Thread Reindl Harald
I really do not understand you

First you would like to see a incomatible change
without any sense because you do not like some code

On the other hand you are crying about the changes in 5.3
because your code which can not live with it since
you ignored warnings long time ago

So this sounds like bc does not interest me as long it affects
me personally


Am 25.07.2010 11:17, schrieb Karoly Negyesi:
[PHP-DEV] Please reconsider supporting PHP 5.2

 A mere year after releasing Version 5.3.0 (Version 5.3.0 30-June-2009)
 you are dropping PHP 5.2 support.
 
 This is a very interesting decision as 5.3.0, compatibility wise, is a
 major release. I always felt it was PHP 6.0 but it was not called so
 because there was a development branched called that (which was later
 abandoned).
 
 Serious BC breaking changes include


Am 23.07.2010 00:54, schrieb Karoly Negyesi:
[PHP-DEV] Remove variable function and method calls

 Given that call_user_func exists I would recommend to remove $foo()
 from PHP Next.

 Observe the logic in the following examples:

 $foo();
 new $foo();
 classname::$foo;
 classname::$foo();

 There is a word for this and that word is madness.

 The simplest is to nuke $foo(). call_user_func() is a perfect replacement.



signature.asc
Description: OpenPGP digital signature


Re: [PHP-DEV] Karoly Negyesi: What do you really want?

2010-07-25 Thread Pierre Joye
hi Reindl,

On Sun, Jul 25, 2010 at 2:06 PM, Reindl Harald h.rei...@thelounge.net wrote:
 I really do not understand you

Please do not top post and (re) consider the tone of your posts, in
general. It could be a language barrier but we are here to discuss
technical issues in the most friendly way.

Cheers,
-- 
Pierre

@pierrejoye | 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] Re: Please reconsider supporting PHP 5.2

2010-07-25 Thread Kalle Sommer Nielsen
Hello

2010/7/25 Karoly Negyesi kar...@negyesi.net:'
 Extensions. APC to this day does not have a stable release for PHP
 5.3. Neither has XCache. I am not even sure how do you imagine
 *anyone* much less everyone upgrading to 5.3 with a production site
 without a stable code cache...?


You should check your sources better regarding APC, have a look at the
APC 3.1.3:
http://pecl.php.net/package-info.php?package=APCversion=3.1.3

Even before 5.3.0 was released, we worked on making APC compatible
with 5.3 which was released only 1 month and 2 weeks after the
release. Even the next release of APC thats going beta soon is having
full support for the latest development branch (5.3.99).

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Please reconsider supporting PHP 5.2

2010-07-25 Thread Olivier B.

Le 25/07/2010 17:15, Kalle Sommer Nielsen a écrit :

Hello

2010/7/25 Karoly Negyesikar...@negyesi.net:'
   

Extensions. APC to this day does not have a stable release for PHP
5.3. Neither has XCache. I am not even sure how do you imagine
*anyone* much less everyone upgrading to 5.3 with a production site
without a stable code cache...?
 


You should check your sources better regarding APC, have a look at the
APC 3.1.3:
http://pecl.php.net/package-info.php?package=APCversion=3.1.3

Even before 5.3.0 was released, we worked on making APC compatible
with 5.3 which was released only 1 month and 2 weeks after the
release. Even the next release of APC thats going beta soon is having
full support for the latest development branch (5.3.99).

   
APC 3.1.x is marked as beta, not stable : 
http://pecl.php.net/package/APC

Maybe it's time to mark it as stable, if it's the case.

Olivier


Re: [PHP-DEV] Re: Please reconsider supporting PHP 5.2

2010-07-25 Thread Karoly Negyesi
I said 'stable'. Last I have seen http://pecl.php.net/package/apc the
latest stable was 3.0.19.

Regards

Karoly Negyesi

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] Re: Karoly Negyesi: What do you really want?

2010-07-25 Thread Karoly Negyesi
 So this sounds like bc does not interest me as long it affects
 me personally

You have this backwards. BC surely interests me but there is no BC,
there is only a pretense of BC so why not break it as we see fit?  And
because of this pretense I have asked not to stop supporting PHP 5.2.

Regards

Karoly Negyesi

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Karoly Negyesi: What do you really want?

2010-07-25 Thread Lukas Kahwe Smith

On 25.07.2010, at 18:05, Karoly Negyesi wrote:

 So this sounds like bc does not interest me as long it affects
 me personally
 
 You have this backwards. BC surely interests me but there is no BC,
 there is only a pretense of BC so why not break it as we see fit?  And
 because of this pretense I have asked not to stop supporting PHP 5.2.


Arguing the same thing in circles is just wasting resources. Could stop your 
posts until you have something novel to post (and have thought it over and 
maybe spend a second to not look like a whiney user, but actually as someone 
who wants to contribute to improve the situation)?

I read you are interested in QAing, so I suggest you check out 
http://qa.php.net/.
Get setup to run at least the RC's (better yet also the alpha/beta releases, 
heck even the nightly snapshots) report your findings and assist the doc team 
in writing the migration guides.

regards,
Lukas Kahwe Smith
m...@pooteeweet.org




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php