On Fri, Aug 31, 2012 at 10:24 PM, Sherif Ramadan wrote:
> >
> > That might actually be something I could use :) But the fun for me
> begins here:
> >
> > $numbers = array();
> > $numbers[-1] = 5;
> > $numbers[] = 6;
> >
> > What would have happened to the keys? Normally [] is equivalent to
> [coun
Sherif Ramadan wrote:
As it stands today, that code would result in the following:
$numbers = array();
$numbers[-1] = 5;
$numbers[] = 6;
var_dump($numbers);
/*
array(2) {
[-1]=>
int(5)
[0]=>
int(6)
}
*/
I think that it is just clarifying this further by adding
$numbers = array(0,1,
>
> This discussion kinda reminds me of some of the debates over AUTO_INCREMENT
> behavior in the MySQL community. Specifically, they end up having to tackle
> the same funcamental, conceptual dilemma: If I assign/insert/whatever an
> arbitrary value to a container that can be incremented, and th
On Sat, Sep 1, 2012 at 4:52 AM, Lester Caine wrote:
> Sherif Ramadan wrote:
>>
>> As it stands today, that code would result in the following:
>>
>> $numbers = array();
>> $numbers[-1] = 5;
>> $numbers[] = 6;
>> var_dump($numbers);
>> /*
>> array(2) {
>>[-1]=>
>>int(5)
>>[0]=>
>>in
>
> $array[0] = 'first element';
> $array[9] = 'second element';
> var_dump($array);
> /*
> array(2) {
> [9]=>
> string(14) "second element"
> [0]=>
> string(13) "first element"
> }
> */
Just correcting this as it was a copy/paste fail... The above code
would produce:
array(2) {
hi Stas,
On Fri, Aug 31, 2012 at 7:31 PM, Stas Malyshev wrote:
> Hi!
>
>> The spl ext has exceptions all around, so if would count spl as "core", we
>> have exceptions in the core already, so it would be ok to add more
>> exceptions where appropriate.
>
> SPL is not a part of basic language synt
Sherif Ramadan wrote:
I can't understand what you mean by "Different means of identifying
position in the array"? If you mean a way to access an array's element
by its position in the array then yes, we already have that. It's
called array_slice() seehttp://php.net/array-slice which allows you
t
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 inability to agree on a default pattern.
In short, the patch uses the ISO-8601 format as the default pattern. The
pattern
On 01/09/12 11:14, 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
unanswered mostly because of the inability to agree on a default pattern.
In short, the patch uses the ISO-8601 forma
hi Will,
On Sat, Sep 1, 2012 at 12:14 PM, 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
> unanswered mostly because of the inability to agree on a default pattern.
>
> In short, t
ok if its place is not in the core, or is it?
--
Best regards,
Axel Etcheverry
Phone : +33 6 84 15 57 52
Twitter : @euskadi31 (http://twitter.com/euskadi31)
Home : http://www.axel-etcheverry.com (http://www.axel-etcheverry.com/)
Audiofanzine : http://fr.audiofanzine.com (http://fr.audiofanzin
On Sat, Sep 1, 2012 at 6:14 AM, 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
> unanswered mostly because of the inability to agree on a default pattern.
>
> In short, the patch us
Lester Caine wrote:
Sherif Ramadan wrote:
I can't understand what you mean by "Different means of identifying
position in the array"? If you mean a way to access an array's element
by its position in the array then yes, we already have that. It's
called array_slice() seehttp://php.net/array-slic
On Sat, Aug 25, 2012 at 6:10 PM, Nikita Popov wrote:
> Hi internals!
>
> I think the generators RFC has been discussed thoroughly enough by
> now, so I opened the vote:
>
> https://wiki.php.net/rfc/generators#vote
>
> Thanks,
> Nikita
The vote ended with 24 in favor and one against. As such t
- Original message -
> On Sat, Aug 25, 2012 at 6:10 PM, Nikita Popov
> wrote:
> > Hi internals!
> >
> > I think the generators RFC has been discussed thoroughly enough by
> > now, so I opened the vote:
> >
> > https://wiki.php.net/rfc/generators#vote
> >
> > Thanks,
> > Nikita
>
> The
On Sat, 01 Sep 2012 18:02:40 +0200, Nikita Popov
wrote:
The vote ended with 24 in favor and one against. As such the RFC is
accepted.
I've merged Nikita's branch in 53351d0.
As to the "exception objection": the behavior of throwing exceptions on
illegal state was written on the RFC wh
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
> unanswered mostly because of the inability to agree on a default pattern.
>
> In short, the patch uses the ISO-
Hi!
>> SPL is not a part of basic language syntax. There are no SPL keywords
>> and no SPL classes used unless you explicitly instantiate those classes.
>> So SPL is different.
>
> End users do not see nor buy the difference between what is Zend/ or
> what is ext/spl (or other) and can't be disab
Stas Malyshev wrote:
Well, not anybody's problem, each guy got his piece
committed, written in his favorite style, matching his unique use case,
and couldn't care less about anything else.
Sounds about right ...
I'm doing it this way and everybody has voted that it's OK so go whistle?
And we ha
On Sun, 02 Sep 2012 01:04:10 +0200, Stas Malyshev
wrote:
SPL is not a part of basic language syntax. There are no SPL keywords
and no SPL classes used unless you explicitly instantiate those
classes.
So SPL is different.
End users do not see nor buy the difference between what is Zend/ o
On 09/01/2012 04:51 PM, Gustavo Lopes wrote
> * In fact, if there is a unifying theme in the usage of exceptions in
> PHP, is that exceptions are used when OOP interfaces are involved (see
> Zend interfaces, SPL, DateTime and PDO -- though optional there). The
> core vs. non-core argument only loo
Hi!
> * If users do not expect exceptions in the core, they are mistaken. There
> are indeed exceptions in the core. See ZEND_FE_RESET and
> zend_interfaces.c. Of course, no evidence has been provided one way or
> another.
This is not right either, but that was done in 2005. We're now in 20
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 cause problems to have co
On Sun, 02 Sep 2012 02:27:02 +0200, Rasmus Lerdorf
wrote:
On 09/01/2012 04:51 PM, Gustavo Lopes wrote
* In fact, if there is a unifying theme in the usage of exceptions in
PHP, is that exceptions are used when OOP interfaces are involved (see
Zend interfaces, SPL, DateTime and PDO -- though
On Sun, 02 Sep 2012 02:37:50 +0200, Stas Malyshev
wrote:
* If users do not expect exceptions in the core, they are mistaken.
There are indeed exceptions in the core. See ZEND_FE_RESET and
zend_interfaces.c. Of course, no evidence has been provided one way or
another.
This is not right eit
Hi!
> 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 used generators with an invalid state would, except
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 used generators w
On 2012-09-01 21:23, Sherif Ramadan wrote:
$array[0] = 'first element';
$array[9] = 'second element';
var_dump($array);
/*
array(2) {
[9]=>
string(14) "second element"
[0]=>
string(13) "first element"
}
*/
Just correcting this as it was a copy/paste fail... The above code
w
On 2012-09-01 20:17, Kris Craig wrote:
This discussion kinda reminds me of some of the debates over AUTO_INCREMENT
behavior in the MySQL community. Specifically, they end up having to
tackle the same funcamental, conceptual dilemma: If I
assign/insert/whatever an arbitrary value to a container
Hi!
> 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
> cause problem
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 angle.
Right now, I see the biggest problem with errors currently
Hi!
> 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 more objectionable.
I definitely did
Hi!
> 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 inability to agree on a default pattern.
This must indicate there's actually no default pattern that is "default
Hi!
I am noticing that the new way we're doing releases in 5.4 is not
completely clear to everybody, so I would like to reiterate some points.
1. 5.4 releases are done from release branch (PHP-5.4.X, e.g. current
one is PHP-5.4.7). This branch is created 2 weeks before the release,
usually on Tue
On Sat, Sep 1, 2012 at 6:36 AM, Pierre Joye wrote:
> hi Will,
>
> On Sat, Sep 1, 2012 at 12:14 PM, 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
> > unanswered mostly because
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
> > unanswered mostly because of the inability to a
On Sat, Sep 1, 2012 at 9:54 PM, Stas Malyshev wrote:
> Hi!
>
> > 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 inability to agree on a default pattern.
>
> This
37 matches
Mail list logo
