Hello Rouven,
the lack of "good" UTF-8 support is a long topic in PHP and improvement (at
least i think) are very welcome at this place!
Before I write an RFC I'd like to get some feedback what you think about
> adding the following functions to PHP 5.6 (possibly more to follow):
> utf8_is_valid,
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
> 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 23 May 2013 22:22, Stas Malyshev 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 progr
Hi Internals!
First let me introduce myself, my name is Rouven Weßling, I'm a student at RWTH
Aachen University and I'm one of the maintainers of the Joomla! Framework (née
Platform). I've been following the internals list for a few months and started
brushing of my C skills for the past couple
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 17:14, Stas Malyshev 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
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 m
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 Inter
> -Original Message-
> From: Sebastian Bergmann [mailto:sebast...@php.net]
> Sent: 23 May 2013 21:18
> To: internals@lists.php.net
> Subject: [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 u
> 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 exceptio
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
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
On 23 May 2013 14:11, Nikita Popov 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 undernea
On Thu, May 23, 2013 at 10:39 PM, Adam Harvey wrote:
> On 23 May 2013 13:31, Nikita Popov wrote:
> > On Sat, May 18, 2013 at 11:48 AM, Nikita Popov
> wrote:
> >
> >> Hi internals!
> >>
> >> I just noticed that we added the PBKDF2 algorithm two times in PHP 5.5.
> >> Once in the hash extension,
On 23 May 2013 13:31, Nikita Popov wrote:
> On Sat, May 18, 2013 at 11:48 AM, Nikita Popov 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
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 make
On Sat, May 18, 2013 at 11:48 AM, Nikita Popov 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_pbkdf
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 ag
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
On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey 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 e
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
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.
23 matches
Mail list logo
