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
On Sun, Sep 2, 2012 at 9:39 AM, Anthony Ferrara 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 a
> different
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
Hi:
this is expected behavior, like:
wrote:
> 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
Derick,
On Sun, Sep 2, 2012 at 1:12 PM, Derick Rethans 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 question
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?
On Sun, Sep 2, 2012 at 7:11 PM, Sherif Ramadan 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 based
>> on 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
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 exp
On Sep 2, 2012 6:08 PM, "Lester Caine" 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
>> everyon
On Sun, Sep 2, 2012 at 5:27 PM, Adam Richardson wrote:
> On Sun, Sep 2, 2012 at 4:41 PM, Sherif Ramadan
> 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 the thread, as everything
> else yo
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 2 September 2012 22:20, Derick Rethans 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 Amsterdam ti
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, for
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
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 (defau
On Sun, 2 Sep 2012, Will Fitch wrote:
> On Sep 2, 2012 4:39 PM, "Andrew Faulds" 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:
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 loss
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 illustr
On Sep 2, 2012 4:39 PM, "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 'date_default_t
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 u
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 'date_defaul
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::IS
On Sun, Sep 2, 2012 at 11:59 AM, Lester Caine 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 applications.
>
>
> --
> L
>
> 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 pre
2012/9/2 Sherif Ramadan
> 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 not necessarily
>
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
> 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:
> $
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
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, 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 improv
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
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 would
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 the
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 im
On 02/09/12 13:55, Pierre Joye wrote:
On Sun, Sep 2, 2012 at 1:35 PM, Derick Rethans 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 more of them.
-
On Sun, Sep 2, 2012 at 1:35 PM, Derick Rethans 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 List
To unsubs
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 excepti
On Sun, 2 Sep 2012, Will Fitch wrote:
> On Sat, Sep 1, 2012 at 9:54 PM, Stas Malyshev wrote:
>
> > > 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 the inabili
On Sun, 2 Sep 2012, Will Fitch wrote:
> On Sat, Sep 1, 2012 at 4:54 PM, Derick Rethans 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 goes
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 wa
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 y
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 implem
On Sun, 02 Sep 2012 03:39:15 +0200, 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 sce
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 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 t
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 Sun, 02 Sep 2012 03:01:06 +0200, Stas Malyshev
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 flow and abandoning the
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
49 matches
Mail list logo
