Rasmus Lerdorf wrote:
On 09/01/2012 05:44 PM, Gustavo Lopes wrote:
More importantly, there is no other satisfactory solution (except a
fatal error). foreach has no return value, so it has no other way to
signal a failure. If we used a notice or a warning here what would
happen is that code that
On Sun, 02 Sep 2012 03:01:06 +0200, Stas Malyshev smalys...@sugarcrm.com
wrote:
For me, it behaves exactly like any other
iterator would behave if you had no more useful elements in it -
meaning, producing no elements. I do not understand why you think it
requires immediate break of the code
Stas Malyshev wrote:
The idea was originally proposed by Marc Easen who created a patch
and asked for help with putting together an RFC. I have yet to see a
formal proposal but on the list Easen modified his idea so that it
should apply to strings alone. With that in mind, would it really
On 02/09/12 02:39, Anthony Ferrara wrote:
Right now, I see the biggest problem with errors currently in PHP is that
there's no easy way of discerning between error types to be able to handle
them. Therefore it's easier to ignore the error than it is to handle it
bluntly. For example, I may want
Will Fitch wrote:
I'm not sure introducing special state to DateTime for it is the best
way to handle it. Also, most applications would have common date format
- which means since the state is per DateTime object, they'd have to
watch that every object produced would have this property set. I
On Sun, 02 Sep 2012 03:39:15 +0200, Anthony Ferrara ircmax...@gmail.com
wrote:
So, while I know there's some discontent about having the core raise
exceptions, let me ask the question differently:
Without moving to exceptions, how could the current error and error
handling mechanisms be
Hi!
Stanislav I though that the discussion on adding this type of functionality
to
strings was already a done deal? Despite the obvious problems it introduces.
I'm not sure what you mean by done deal. There was this RFC:
https://wiki.php.net/rfc/strncmpnegativelen
but that wasn't
Hi!
Hi, Stas. This has been on my mind as well. I've considered that maybe
an INI wide setting would be beneficial here. In fact, there are many
places within applications I've worked on where the format for many
DateTime objects are the same. What are your thoughts on that?
I think yet
Stas Malyshev wrote:
Stanislav I though that the discussion on adding this type of functionality to
strings was already a done deal? Despite the obvious problems it introduces.
I'm not sure what you mean by done deal. There was this RFC:
https://wiki.php.net/rfc/strncmpnegativelen
but that
On Sun, 2 Sep 2012, Will Fitch wrote:
On Sat, Sep 1, 2012 at 4:54 PM, Derick Rethans der...@php.net wrote:
On Sat, 1 Sep 2012, Will Fitch wrote:
I would like to officially introduce an RFC with a patch to implement
__toString to DateTime. This is a commonly requested feature that
On Sun, 2 Sep 2012, Will Fitch wrote:
On Sat, Sep 1, 2012 at 9:54 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
I would like to officially introduce an RFC with a patch to
implement __toString to DateTime. This is a commonly requested
feature that goes unanswered mostly because of
Andrew:
I don't wish to derail this thread from the get-go, but what's your
opposition to moving to exceptions?
I'm absolutely for moving to exceptions. I asked this question as a
thought exercise to see 1. If the current error system can be improved, or
2. To identify if it can't, and
On Sun, Sep 2, 2012 at 1:35 PM, Derick Rethans der...@php.net wrote:
We should absolutely NOT add ini settings for this. They make things
unportable.
Agreed.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing
On 02/09/12 13:55, Pierre Joye wrote:
On Sun, Sep 2, 2012 at 1:35 PM, Derick Rethans der...@php.net wrote:
We should absolutely NOT add ini settings for this. They make things
unportable.
Agreed.
Add my name to the list. PHP's ini settings are one of its bad points,
IMO. We don't need any
I think allowing to change teh default format would be horrible. If
libraries (such as Doctrine would) use this internally, they are at the
will of users not to fiddle with this setting. Not to speak about libraries
that contradict each other.
If there was a format, it would have to be constant
On 02/09/12 14:40, Benjamin Eberlei wrote:
I think allowing to change teh default format would be horrible. If
libraries (such as Doctrine would) use this internally, they are at
the will of users not to fiddle with this setting. Not to speak about
libraries that contradict each other.
If
Andrew Faulds wrote:
I think allowing to change teh default format would be horrible. If libraries
(such as Doctrine would) use this internally, they are at the will of users
not to fiddle with this setting. Not to speak about libraries that contradict
each other.
If there was a format, it
On Sat, 1 Sep 2012, Stas Malyshev wrote:
illegal state was written on the RFC when voting opened, and the RFC
was accepted almost unanimously. As the proposal was accepted as
such, I saw no valid reason not to merge. In fact, changing the
proposal after it was voted on would be much
On Sun, 2 Sep 2012, Anthony Ferrara wrote:
I don't wish to derail this thread from the get-go, but what's your
opposition to moving to exceptions?
I'm absolutely for moving to exceptions. I asked this question as a
thought exercise to see 1. If the current error system can be improved, or
Hi all,
I have a question about the internal implementation of PHP's hashtables. I
did some researches, but I didn't find the answer.
Here is an example of what I would like to understand.
Start by creating an array:
$a = array();
Fill it, using implicit and explicit keys:
$a[] = 'cc';
$a[1]
On Sun, 2 Sep 2012, Andrew Faulds wrote:
On 02/09/12 14:40, Benjamin Eberlei wrote:
I think allowing to change teh default format would be horrible. If
libraries (such as Doctrine would) use this internally, they are at the will
of users not to fiddle with this setting. Not to speak about
Hi all,
I have a question about the internal implementation of PHP's hashtables. I
did some researches, but I didn't find the answer.
Here is an example of what I would like to understand.
Start by creating an array:
$a = array();
Fill it, using implicit and explicit keys:
$a[] =
Derick Rethans wrote:
Then ISO8601, please. It's a single, unambiguous Date and Time format.
No it's not unambigious:
Derick - is this effect just due to daylight saving differences, or IS it a bit
more complex than that?
Personally I don't want any timezone/offset displayed as I expect it
2012/9/2 Sherif Ramadan theanomaly...@gmail.com
To clarify, this particular functionality you're using as an example
array_unshift really isn't specific to the internal implementation
of hashtables in PHP. That is to say that this side-effect you're
describing is specific to that function and
OK, thanks for the information. It explains why I didn't find anything in
the HashTable structure (unlike iterator pointer or the next free key).
Yes, because the hashtable is an ordered map. The only way to
logically prepend to it is to rework the whole thing. That's generally
how you
On Sun, Sep 2, 2012 at 11:59 AM, Lester Caine les...@lsces.co.uk wrote:
Personally I don't want any timezone/offset displayed as I expect it to be a
UTC time by default on the server, rather than any offset time, which is why
I'm with you that it should only be changed via user space
On 02/09/12 18:20, Derick Rethans wrote:
No it's not unambigious:
$ php -r 'date_default_timezone_set(Europe/London); echo
date_create()-format(DateTime::ISO8601), \n;'
2012-09-02T18:17:36+0100
$ php -r 'date_default_timezone_set(Africa/Niamey); echo
date_create()-format(DateTime::ISO8601),
On Sun, 2 Sep 2012, Andrew Faulds wrote:
On 02/09/12 18:20, Derick Rethans wrote:
No it's not unambigious:
$ php -r 'date_default_timezone_set(Europe/London); echo
date_create()-format(DateTime::ISO8601), \n;'
2012-09-02T18:17:36+0100
$ php -r
On 02/09/12 21:45, Derick Rethans wrote:
Yes, and that format is ambigious like I just illustrated. cheers, Derick
No, you just demonstrated the time offset format is ambiguous, not the
UTC format.
--
Andrew Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To
On Sep 2, 2012 4:39 PM, Andrew Faulds a...@ajf.me wrote:
On 02/09/12 18:20, Derick Rethans wrote:
No it's not unambigious:
$ php -r 'date_default_timezone_set(Europe/London); echo
date_create()-format(DateTime::ISO8601), \n;'
2012-09-02T18:17:36+0100
$ php -r
On Sun, 2 Sep 2012, Lester Caine wrote:
Derick Rethans wrote:
Then ISO8601, please. It's a single, unambiguous Date and Time format.
No it's not unambigious:
Derick - is this effect just due to daylight saving differences, or IS it a
bit more complex than that?
This one illustrated DST
On Sun, 2 Sep 2012, Andrew Faulds wrote:
On 02/09/12 21:45, Derick Rethans wrote:
Yes, and that format is ambigious like I just illustrated. cheers,
Derick
No, you just demonstrated the time offset format is ambiguous, not the
UTC format.
Yes, I am saying that ISO8601 is lossy - and
On Sun, 2 Sep 2012, Will Fitch wrote:
On Sep 2, 2012 4:39 PM, Andrew Faulds a...@ajf.me wrote:
On 02/09/12 18:20, Derick Rethans wrote:
No it's not unambigious:
..snip...
I'm a little confused as to what is going on here, but ISO8601 has a UTC
format, -MM-DDTHH:MM:SSZ.
I
On 02/09/12 21:50, Derick Rethans wrote:
Yes, I am saying that ISO8601 is lossy - and that is something that
shouldn't be the default format.
Lossy of what? Local timezone?
ISO 8601 is the single unambiguously ordered (no mm-dd/dd-mm confusion),
international standard, machine-readable
On Sun, 2 Sep 2012, Andrew Faulds wrote:
On 02/09/12 21:50, Derick Rethans wrote:
Yes, I am saying that ISO8601 is lossy - and that is something that
shouldn't be the default format.
Lossy of what? Local timezone?
ISO 8601 is the single unambiguously ordered (no mm-dd/dd-mm
Andrew Faulds wrote:
Yes, I am saying that ISO8601 is lossy - and that is something that
shouldn't be the default format.
Lossy of what? Local timezone?
ISO 8601 is the single unambiguously ordered (no mm-dd/dd-mm confusion),
international standard, machine-readable (default in ECMAScript,
On 2 September 2012 22:20, Derick Rethans der...@php.net wrote:
Yeah, I understand you don't see a reason. That's what scares me. For
debugging I definetely wouldn't want to have my datetimes mangled to
just show UTC. I wouldn't even be able to see the difference between 4pm
London and 5pm
Peter Cowburn wrote:
Finally, why should echo $datetime; be expected to work at all,
since 95% of the time it's only going to be echo'd plain like that for
debugging purposes as we'll never pick the right format to use in
everyone's code. When needing to set the default (read:
per-instance)
On Sun, Sep 2, 2012 at 5:27 PM, Adam Richardson simples...@gmail.com wrote:
On Sun, Sep 2, 2012 at 4:41 PM, Sherif Ramadan theanomaly...@gmail.com
wrote:
You're right. I don't know what I was thinking when I said linked list. :)
No problem :)
You might want to post a quick correction to
On Sep 2, 2012 6:08 PM, Lester Caine les...@lsces.co.uk wrote:
Peter Cowburn wrote:
Finally, why should echo $datetime; be expected to work at all,
since 95% of the time it's only going to be echo'd plain like that for
debugging purposes as we'll never pick the right format to use in
Hi,
Just looking at the foreach list behaviour and it does this...
$i = [1, 2, 3];
foreach($i as list($a, $b))
var_dump($a, $b);
Outputs
NULL
NULL
NULL
NULL
NULL
NULL
There is no test I can see covering this, so cannot tell if its
expected.
To me, $i does not meet the
I see how this may work for strings and simple vectors, but what about this:
$a = array(-1 = foo, -2 = bar); echo $a[-1];
It should keep returning foo, right? So then the question is - what
$array[-1] actually means?
Context would be the deciding factor, i.e. perhaps restrict the shortcut's
On Sun, Sep 2, 2012 at 7:11 PM, Sherif Ramadan theanomaly...@gmail.com wrote:
It is problematic because that is what we choose to make it. Right now, a
catchable fatal error is produced. That is problematic. ISO8601 is not
lossy nor is UTC. It can be taken by any other language and converted
On 03.09.2012, at 01:11, sle...@pipeline.com wrote:
I see how this may work for strings and simple vectors, but what about this:
$a = array(-1 = foo, -2 = bar); echo $a[-1];
It should keep returning foo, right? So then the question is - what
$array[-1] actually means?
Context would be
Derick,
On Sun, Sep 2, 2012 at 1:12 PM, Derick Rethans der...@php.net wrote:
On Sun, 2 Sep 2012, Anthony Ferrara wrote:
I don't wish to derail this thread from the get-go, but what's your
opposition to moving to exceptions?
I'm absolutely for moving to exceptions. I asked this
Hi:
this is expected behavior, like:
?php
list($a, $b) = 1;
var_dump($a);
thanks
On Mon, Sep 3, 2012 at 7:07 AM, Jared Williams
jared.willi...@ntlworld.com wrote:
Hi,
Just looking at the foreach list behaviour and it does this...
$i = [1, 2, 3];
foreach($i as list($a, $b))
On 09/01/2012 06:39 PM, Anthony Ferrara wrote:
So, while I know there's some discontent about having the core raise
exceptions, let me ask the question differently:
Without moving to exceptions, how could the current error and error
handling mechanisms be improved to make the scenario I
On Sun, Sep 2, 2012 at 9:39 AM, Anthony Ferrara ircmax...@gmail.com wrote:
Hi all,
There's been a lot of discussion around whether or not to include
exceptions for core (no class implementations) errors or not. There's been
a lot said on both sides. However, I'd like to pose the question from
Rasmus Lerdorf wrote:
On 09/01/2012 06:39 PM, Anthony Ferrara wrote:
So, while I know there's some discontent about having the core raise
exceptions, let me ask the question differently:
Without moving to exceptions, how could the current error and error
handling mechanisms be improved to make
49 matches
Mail list logo
