[PHP-DEV] PHP 5.3.26RC1 and 5.4.16RC1 Released for Testing!
Hi! We've released PHP 5.3.26RC1 and 5.4.16RC1 which can be found here: 5.3.26RC1: http://downloads.php.net/johannes/php-5.3.26RC1.tar.bz2 http://downloads.php.net/johannes/php-5.3.26RC1.tar.gz 5.4.16RC1: http://downloads.php.net/stas/php-5.4.16RC1.tar.bz2 http://downloads.php.net/stas/php-5.4.16RC1.tar.gz Windows binaries for both, as always, are at: http://windows.php.net/qa/ These are regular bugfix releases, the full list of issues fixed can be found in the NEWS files. Please test and report if anything is broken. If no critical issues is found in this RC, the final version will be released in two weeks. Regards, Stas Malyshev, Johannes Schlüter -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
I'm probably not the typical PHP user; I spend 99% of my PHP time using the CLI (and not web SAPIs). This means that I frequently run PHP without an .ini file. As a result, when I use any of the date/time functionality I invariably end up with this awesomeness: Warning: date(): It is not safe to rely on the system's timezone settings blah blah blah. Could I run `$ php -d date.timezone=UTC myfile.php`? Of course, but should that really be necessary? It seems to me this warning caters to the very lowest common denominator among PHP devs who can't be bothered to understand how PHP handles timezones. The warning also seems to assume that people only use PHP as a web framework and not as an actual programming language (otherwise I wouldn't have to explain to the CLI which timezone I want to use). I don't need php.ini ... I want to use PHP to *program*. If it's going to default to UTC anyway should there really be an E_WARNING? Can't PHP just quietly use UTC? The U in UTC *does* stand for Universal, after all. It's a sensible default and as such shouldn't merit a warning. Besides, if someone doesn't understand what's happening and gets unexpected date/time results the first thing they're going to do (I hope) is hit their favorite search engine for set PHP timezone. Perhaps I'm the only person to experience ongoing annoyance at the hands of this protective feature? Is there a substantive reason why this warning exists other than the error message's suggestion that you most likely misspelled the timezone identifier? I understand that one of PHP's most attractive features is ease-of-use for programming novices but you can only go so far in preventing people who don't know what they're doing from shooting themselves in the foot. I'm not sure if it's possible but perhaps a compromise might be to disable this warning in the CLI, at least? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey rdlow...@gmail.com wrote: I'm probably not the typical PHP user; I spend 99% of my PHP time using the CLI (and not web SAPIs). This means that I frequently run PHP without an .ini file. As a result, when I use any of the date/time functionality I invariably end up with this awesomeness: Warning: date(): It is not safe to rely on the system's timezone settings blah blah blah. Could I run `$ php -d date.timezone=UTC myfile.php`? Of course, but should that really be necessary? It seems to me this warning caters to the very lowest common denominator among PHP devs who can't be bothered to understand how PHP handles timezones. The warning also seems to assume that people only use PHP as a web framework and not as an actual programming language (otherwise I wouldn't have to explain to the CLI which timezone I want to use). I don't need php.ini ... I want to use PHP to *program*. If it's going to default to UTC anyway should there really be an E_WARNING? Can't PHP just quietly use UTC? The U in UTC *does* stand for Universal, after all. It's a sensible default and as such shouldn't merit a warning. Besides, if someone doesn't understand what's happening and gets unexpected date/time results the first thing they're going to do (I hope) is hit their favorite search engine for set PHP timezone. Perhaps I'm the only person to experience ongoing annoyance at the hands of this protective feature? Is there a substantive reason why this warning exists other than the error message's suggestion that you most likely misspelled the timezone identifier? I understand that one of PHP's most attractive features is ease-of-use for programming novices but you can only go so far in preventing people who don't know what they're doing from shooting themselves in the foot. I'm not sure if it's possible but perhaps a compromise might be to disable this warning in the CLI, at least? Fully agreed. The warning is very annoying when using CLI. And even when not using CLI: The timezone is usually only relevant in production. I don't care if times are off a few hours when developing stuff. Nikita
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
Hi! I'm probably not the typical PHP user; I spend 99% of my PHP time using the CLI (and not web SAPIs). This means that I frequently run PHP without an .ini file. As a I'm not sure how this follows - CLI is capable of using ini file just like the rest of SAPIs. Why not create it? The U in UTC *does* stand for Universal, after all. It's a sensible default and as such shouldn't I don't think it's a sensible default - people don't actually use UTC when considering dates. A minority of people can use timezone that coincides with UTC, but not very many use actual UTC. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #64910: Line number of $e = new Exception vs. line number of throw $e
Hi! The error message that is created for an uncaught exception as well as the stacktrace of an exception list the number of the line on which the exception object was created. I would expect this to be number of the line on which the exception is raised using the throw statement. Derick agrees with me that this is a bug. We propose to update the file and line properties of the exception object in the zend_throw_exception_internal() and zend_throw_exception() functions. Would such a change be accepted? Does it require an RFC? Thanks! Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: hash_pbkdf2 vs openssl_pbkdf2
On Sat, May 18, 2013 at 11:48 AM, Nikita Popov nikita@gmail.com wrote: Hi internals! I just noticed that we added the PBKDF2 algorithm two times in PHP 5.5. Once in the hash extension, once in the OpenSSL extension. The hash_pbkdf2 function was added via this RFC: https://wiki.php.net/rfc/hash_pbkdf2 The openssl_pbkdf2 function probably was not noticed at that time because it was just commited, but not mentioned anywhere else (NEWS, UPGRADING, etc). Only saw it in vrana's documentation updates just now. The relevant commit is here: https://github.com/php/php-src/commit/f4847ef It would be nice if we could have only one of those functions. I'm currently tending towards the hash_ variant because of the commit message of the openssl_ function: No easy way to put these in the hash extension since we don't really support optional parameters to certain algorithms. Implemented in openssl for now since it has it already and is pretty stable. Only SHA1 is confirmed to work as an algorithm but openssl has a parameter so it can be changed in the future. It seems that the author already would have preferred it in the hash extension and that the openssl variant only works with sha1 (or was only tested with it? not sure). Nikita No more opinions? It would be nice to have this resolved before 5.5, otherwise there will be no way back. Nikita
Re: [PHP-DEV] Bug #64910: Line number of $e = new Exception vs. line number of throw $e
Hi!
Derick agrees with me that this is a bug. We propose to update the file
and line properties of the exception object in the
zend_throw_exception_internal() and zend_throw_exception() functions.
Would such a change be accepted? Does it require an RFC?
On one hand, I think it makes sense - nobody really cares where the
exception was created... But there's one problem here:
try {
//stuff
} catch(Exception $e) {
$logger-log(Oops, exception!);
throw $e;
}
If we update file/line here, we lose original exception information and
file/line in the exception becomes useless. Right now, since 99.99% of
the code does throw new, it is always useful. So how you would propose
to solve this?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: hash_pbkdf2 vs openssl_pbkdf2
On 23 May 2013 13:31, Nikita Popov nikita@gmail.com wrote: On Sat, May 18, 2013 at 11:48 AM, Nikita Popov nikita@gmail.com wrote: Hi internals! I just noticed that we added the PBKDF2 algorithm two times in PHP 5.5. Once in the hash extension, once in the OpenSSL extension. The hash_pbkdf2 function was added via this RFC: https://wiki.php.net/rfc/hash_pbkdf2 The openssl_pbkdf2 function probably was not noticed at that time because it was just commited, but not mentioned anywhere else (NEWS, UPGRADING, etc). Only saw it in vrana's documentation updates just now. The relevant commit is here: https://github.com/php/php-src/commit/f4847ef It would be nice if we could have only one of those functions. I'm currently tending towards the hash_ variant because of the commit message of the openssl_ function: No easy way to put these in the hash extension since we don't really support optional parameters to certain algorithms. Implemented in openssl for now since it has it already and is pretty stable. Only SHA1 is confirmed to work as an algorithm but openssl has a parameter so it can be changed in the future. It seems that the author already would have preferred it in the hash extension and that the openssl variant only works with sha1 (or was only tested with it? not sure). Nikita No more opinions? It would be nice to have this resolved before 5.5, otherwise there will be no way back. I'm not really convinced this is a problem in practice — hash_pbkdf2() is likely to be the commonly used one because it doesn't have the OpenSSL dependency, but it probably doesn't hurt to have the ability to also call OpenSSL's independent implementation (say, if a bug is found in one or the other). Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: hash_pbkdf2 vs openssl_pbkdf2
On Thu, May 23, 2013 at 10:39 PM, Adam Harvey ahar...@php.net wrote: On 23 May 2013 13:31, Nikita Popov nikita@gmail.com wrote: On Sat, May 18, 2013 at 11:48 AM, Nikita Popov nikita@gmail.com wrote: Hi internals! I just noticed that we added the PBKDF2 algorithm two times in PHP 5.5. Once in the hash extension, once in the OpenSSL extension. The hash_pbkdf2 function was added via this RFC: https://wiki.php.net/rfc/hash_pbkdf2 The openssl_pbkdf2 function probably was not noticed at that time because it was just commited, but not mentioned anywhere else (NEWS, UPGRADING, etc). Only saw it in vrana's documentation updates just now. The relevant commit is here: https://github.com/php/php-src/commit/f4847ef It would be nice if we could have only one of those functions. I'm currently tending towards the hash_ variant because of the commit message of the openssl_ function: No easy way to put these in the hash extension since we don't really support optional parameters to certain algorithms. Implemented in openssl for now since it has it already and is pretty stable. Only SHA1 is confirmed to work as an algorithm but openssl has a parameter so it can be changed in the future. It seems that the author already would have preferred it in the hash extension and that the openssl variant only works with sha1 (or was only tested with it? not sure). Nikita No more opinions? It would be nice to have this resolved before 5.5, otherwise there will be no way back. I'm not really convinced this is a problem in practice — hash_pbkdf2() is likely to be the commonly used one because it doesn't have the OpenSSL dependency, but it probably doesn't hurt to have the ability to also call OpenSSL's independent implementation (say, if a bug is found in one or the other). Adam If a bug is found we fix it. Proving several implementations of the same thing to account for potential bugs isn't a good idea imho. If two functions for the same thing exist people need to wonder about which one of them should be used, and in the worst case decide to use a pattern like if function1 exists call function1, if function2 exists call function2, etc. Just like nowadays to generate a random string you usually check something like four of five different functions. I think it's preferable to have one and only one function in a default-enabled extension. Nikita
Re: [PHP-DEV] Re: hash_pbkdf2 vs openssl_pbkdf2
On 23 May 2013 14:11, Nikita Popov nikita@gmail.com wrote: If a bug is found we fix it. Proving several implementations of the same thing to account for potential bugs isn't a good idea imho. It's not a very good example, I admit, but my point is that it's not as though they're actually the same code underneath. If two functions for the same thing exist people need to wonder about which one of them should be used, and in the worst case decide to use a pattern like if function1 exists call function1, if function2 exists call function2, etc. Just like nowadays to generate a random string you usually check something like four of five different functions. I think it's preferable to have one and only one function in a default-enabled extension. I think that horse bolted about a decade ago. Assuming the OpenSSL version does actually work properly, I don't see why it's an issue. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Cannot call constructor
Consider this common scenario:
I use some OOP library, that is a black box and I like it that way.
As part of the integration, I need to extend one of the library's
classes:
class App_bar extends Library_foo{
function __construct(){
//do whatever I need to do here.
}
}
So I write this code, and it works, and I'm happy.
Years go by and new releases of the library come out, steadily
improving features and fixing bugs etc.
But at some point, the library needed a resource in a __construct()
somewhere in the ancestry of Library_foo, to perform something at the
time of construction.
So they re-factored or re-implemented the black box library to have a
constructor in Library_foo class, or any of its numerous ancestors.
Suddenly my code doesn't work. Maybe the resource is only needed under
certain conditions. So their __construct doesn't get called, but
nothing bad happens until the circumstances where they need the
__construct called.
So now I don't just have a bug, I have an intermittent bug.
And as much as we all like to think our testing covers 100% of the
functionality...
I'm tearing my hair out trying to find where things went wrong in code
that worked for years.
Right now, to avoid this situation, you have to do:
if (method_exists(get_parent_class(), '__construct'))
parent::__construct();
If you don't check for the method existing, you get:
Fatal error: Cannot call constructor ...
I don't want to have an intimate knowledge of the internals of the
library; just the documented API. That's one of the major reasons for
using a library.
I would think that as PHP climbs up the chain of extends et al, if
it never found a parent method, if wouldn't complain about it, much
less E_FATAL...
I mean, so you didn't find a method that's not there to find. And I
should call parent::__construct just in case there is one there,
because I don't know, or care, really, how the black box is
implemented. So long as the library does what's on the tin (in the
docs).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cannot call constructor
Hi! Right now, to avoid this situation, you have to do: if (method_exists(get_parent_class(), '__construct')) parent::__construct(); If you don't check for the method existing, you get: Fatal error: Cannot call constructor ... This makes a lot of sense. I think we also discussed this idea some time ago, but it didn't go anywhere that time... Right now I add empty ctor in almost all base classes just because of this thing. I think having implicit empty ctor would make a lot of things easier. Same would probably do for dtor. How about creating an RFC about it? :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #64910: Line number of $e = new Exception vs. line number of throw $e
On one hand, I think it makes sense - nobody really cares where the
exception was created... But there's one problem here:
try {
//stuff
} catch(Exception $e) {
$logger-log(Oops, exception!);
throw $e;
}
If we update file/line here, we lose original exception information and
file/line in the exception becomes useless. Right now, since 99.99% of
the code does throw new, it is always useful. So how you would
propose
to solve this?
rethrow $e;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #64910: Line number of $e = new Exception vs. line number of throw $e
Hi! the code does throw new, it is always useful. So how you would propose to solve this? rethrow $e; Yes, this is definitely an option, but requires a new keyword. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
I guess my point is that I don't believe default settings should trigger errors. If it's a default setting, it's a default setting. Document it and move on. It's then the user's responsibility to define that value correctly if he/she wants something other than the default. I don't personally see much difference between triggering E_WARNING for date.timezone and -- for example -- open_basedir. There's no error to tell me that my script can access the entire filesystem without an open_basedir setting and that this could be a potential security risk. There's no E_WARNING to say that the default memory_limit value is 128M and that if I want to use more than that I need to define it in php.ini. Where does it stop? It seems like an eminently unsustainable practice to trigger errors for every possible oops in your .ini file. For me, the date.timezone warning has no positive benefit and provides real annoyance every single day. Is that the case for others? I can't say, that's why I'm complaining on the internals list :) On Thu, May 23, 2013 at 4:10 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I'm probably not the typical PHP user; I spend 99% of my PHP time using the CLI (and not web SAPIs). This means that I frequently run PHP without an .ini file. As a I'm not sure how this follows - CLI is capable of using ini file just like the rest of SAPIs. Why not create it? The U in UTC *does* stand for Universal, after all. It's a sensible default and as such shouldn't I don't think it's a sensible default - people don't actually use UTC when considering dates. A minority of people can use timezone that coincides with UTC, but not very many use actual UTC. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #64910: Line number of $e = new Exception vs. line number of throw $e
On 23 May 2013 17:14, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! the code does throw new, it is always useful. So how you would propose to solve this? rethrow $e; Yes, this is definitely an option, but requires a new keyword. We could use a C++ style throw; as an implicit rethrow. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On Thu, 23 May 2013, Daniel Lowrey wrote: I guess my point is that I don't believe default settings should trigger errors. If it's a default setting, it's a default setting. No - you, as an admin, are required to make an informed decision on what you want your timezone to be. There have been way too many bug reports where people had no clue, so now we throw a warning. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #64910: Line number of $e = new Exception vs. line number of throw $e
On 23 May 2013 22:22, Stas Malyshev smalys...@sugarcrm.com wrote: If we update file/line here, we lose original exception information and file/line in the exception becomes useless. Right now, since 99.99% of the code does throw new, it is always useful. So how you would propose to solve this? As a PHP programmer, I would always expect the file/line to refer to the throw statement that has thrown it last. If I wanted to keep track of an exception being rethrown, I'd use nested exceptions (Exception's constructor's third parameter.) Hope that helps. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cannot call constructor
I use some OOP library, that is a black box and I like it that way. Hmm, there's well-documented, change-controlled, trustable API that you shouldn't try to work around and then there's black box. I'm not sure the latter ever sounds like a good thing... I've always used it as a bad word. Suddenly my code doesn't work. Maybe the resource is only needed under certain conditions. So their __construct doesn't get called, but nothing bad happens until the circumstances where they need the __construct called. If their __construct suddenly becomes mandatory, they are deprecating something they (I presume explicitly) supported in the past: ctor overrides without call super. So either they put this in giant blinking text in their UPDATING file and you missed it, or they broke backward compatibility and didn't know it or didn't care. If I were faced with their situation, I'd make the ctor final to make damn sure you realized something was wrong. Then I would say overriding __construct is no longer supported because continuing to support it means mandating call super, which is an impossible contract for the language (this anguage) to enforce. I would abstract the whole thing out to an initChild() type pattern and so on. If you have to change your code, them's the breaks, as long as they give a clear path. I don't think the solution is to work around such mistakes on the part of a lib developer by silencing (?) calls to a nonexistent method _in addition to_ mandating call super -- IMO, that's even smellier than call super on its own. Why not add auto-super contracts to PHP instead (which would include skipping nonexistent super methods)? Making the undefined method error catchable instead of fatal I agree with, though. More like the more catchable world of Reflection. -- Sandy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On 2013-05-23 22:10, Stas Malyshev wrote: The U in UTC *does* stand for Universal, after all. It's a sensible default and as such shouldn't I don't think it's a sensible default - people don't actually use UTC when considering dates. A minority of people can use timezone that coincides with UTC, but not very many use actual UTC. I was wondering - why not get time zone info from operating system? It's should be quite easy on both *nixes and Windows. That way default value would be from operating system, with possibility to override it in .ini. --Leszek -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
