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
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
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
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
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
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:
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
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
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
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
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
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
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
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 -
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
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.
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
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
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.
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
20 matches
Mail list logo
