Re: [PHP-DEV] $obj->attr::method() is not allowed

Hi! > The problem is that the only formal definition of the language _is_ the > parser - there's no grammar outside > zend_language_scanner.l/zend_langauge_parser.y. I'm not sure - why exactly is it a problem here? I can understand how having such document might be useful and interesting (not u

Re: [PHP-DEV] Release scheduling, branching & NEWS for 5.4

hi Stas! On Mon, Sep 3, 2012 at 11:58 PM, Stas Malyshev wrote: >> And no BC in 5.5 as well. Which will cause us some issue for 5.5 as >> master actually has BC breaks as far as I remember. > > We accept binary API changes in 5.5, Right, that's totally fine. > but only very slight PHP-level API

Re: Re: [PHP-DEV] $obj->attr::method() is not allowed

On 2012-09-04 04:17, Laruence wrote: On Tue, Sep 4, 2012 at 12:05 AM, Andrew Faulds wrote: On 03/09/12 17:03, Laruence wrote: It is great parser(simple and fast) which make php works well for years.. No, it's not, it's overly complex. You have to define all sorts of different expression and

Re: [PHP-DEV] Re: RFC Property get/set syntax

On Mon, Sep 3, 2012 at 6:28 PM, Matt Ficken wrote: > I have created a single build combining the property get/set RFC and > Generator RFC. > > On Windows, there are some regressions due to the branch not included many > of the recent fixes for Windows. Otherwise, on Windows and Linux, there > are

[PHP-DEV] Re: RFC Property get/set syntax

I have created a single build combining the property get/set RFC and Generator RFC. On Windows, there are some regressions due to the branch not included many of the recent fixes for Windows. Otherwise, on Windows and Linux, there aren't regressions due to the property get/set RFC. The PHP o

RE: [PHP-DEV] Re: [VOTE] Generators

I have created a single build combining the Generator RFC and the property getter/setter RFC. On Windows, one of the Generator tests fails (tests\generators\clone_with_stack.phpt), but all pass on Linux. There are some regressions due to the branch not included many of the recent fixes for Wi

Re: [PHP-DEV] Re: Are exceptions allowed in php core?

On 09/03/2012 04:31 PM, Alex Aulbach wrote: > 2012/9/4 Gustavo Lopes : >>> Following this logic, we'd have to convert all E_NOTICE and E_STRICT to >>> fatal errors or exceptions - they are usually produced by programming >>> errors and aren't meant to be caught by surrounding code (actually, >>> ca

[PHP-DEV] The Photographer's Guide to Etosha National Park - Reminder

Would you like to return home from your Etosha safari with amazing photos ? If yes, then this ebook is for you . You may have just one chance to capture the moments that you witness. You can get a head start with your safari and know important information up-front. With this affordable eBook

Re: [PHP-DEV] Re: Are exceptions allowed in php core?

2012/9/4 Gustavo Lopes : >> Following this logic, we'd have to convert all E_NOTICE and E_STRICT to >> fatal errors or exceptions - they are usually produced by programming >> errors and aren't meant to be caught by surrounding code (actually, >> can't). But I don't see anybody benefiting from this

Re: [PHP-DEV] Re: Are exceptions allowed in php core?

Hi! > to be gained vs. the additional risk. And there is little to no benefit > in a model where rewinding a closed iterator is allowed, so the > threshold for acceptable risk is very low. This is not a difficult case > at all, IMHO. We are discussing whether it should lead to the fatal error.

Re: [PHP-DEV] Re: Are exceptions allowed in php core?

Hi! > First, E_NOTICE exists to permit a compromise between people like Zeev > that think its introduction was an error and that one should be able to > refer to undefined variables and people who prefer a stricter model. For > the programmers that follow this stricter model, an E_NOTICE ends u

Re: [PHP-DEV] Re: Are exceptions allowed in php core?

Em 2012-09-03 23:51, Stas Malyshev escreveu: I've replied here: http://www.mail-archive.com/internals@lists.php.net/msg60706.html I have a feeling you're concocting a very far-reaching scenarios and making a lot of unbased assumptions there to arrive to pre-defined conclusions. Any programming

Re: [PHP-DEV] Re: Are exceptions allowed in php core?

Em 2012-09-03 23:54, Stas Malyshev escreveu: Hi! indicating such mental model is widespread and (2) given that the exceptions you claim to be surprising don't happen but for a programming error (i.e. they're not exceptions that need to be caught). Following this logic, we'd have to convert

Re: [PHP-DEV] Release scheduling, branching & NEWS for 5.4

Hi! > And no BC in 5.5 as well. Which will cause us some issue for 5.5 as > master actually has BC breaks as far as I remember. We accept binary API changes in 5.5, but only very slight PHP-level API changes (such as removal of functions like logo GUIDs). Another important point - any such chang

Re: [PHP-DEV] Re: Are exceptions allowed in php core?

Hi! > indicating such mental model is widespread and (2) given that the > exceptions you claim to be surprising don't happen but for a programming > error (i.e. they're not exceptions that need to be caught). Following this logic, we'd have to convert all E_NOTICE and E_STRICT to fatal errors o

Re: [PHP-DEV] Re: Are exceptions allowed in php core?

Hi! > I've replied here: > http://www.mail-archive.com/internals@lists.php.net/msg60706.html I have a feeling you're concocting a very far-reaching scenarios and making a lot of unbased assumptions there to arrive to pre-defined conclusions. Any programming error can cost a business money, and a

Re: [PHP-DEV] Re: Are exceptions allowed in php core?

Hi! > They are seen and promoted as core features. Whether we like that idea > or not is not really relevant. We messed that up by making most of the > "Standard" PHP Library an extension for only political and licensing > reasons. I think you using "core" here in two difference meanings, and the

Re: [PHP-DEV] Re: Support negative indexes for arrays and strings

Hi! > The terminology "negative indexing" seems to imply that the feature > should work with arrays. To restrict it to just strings might involve > creating a term one would only associate with strings. I do not see any way to change behavior of $array[-1] that would make sense. So either only st

Re: [PHP-DEV] Foreach list behaviour

On 03/09/12 18:46, Sherif Ramadan wrote: It should absolute not cast anything. list($a, $b) = $c; is the equivalent of saying $a = $c[0]; $b = $c[1]; In this case $c just happens to be a scalar value and as such you can not derive anything from the scalar value in that context. It is implicitly

Re: [PHP-DEV] Foreach list behaviour

On Mon, Sep 3, 2012 at 1:36 PM, Andrew Faulds wrote: > On 03/09/12 18:35, Sherif Ramadan wrote: >> >> On Mon, Sep 3, 2012 at 4:20 AM, Derick Rethans wrote: >>> >>> Ew, that's quite nasty (in both cases). Is there a way how we could turn >>> those into a notice or so? >>> >>> cheers, >>> Derick >>

Re: [PHP-DEV] Foreach list behaviour

On 03/09/12 18:35, Sherif Ramadan wrote: On Mon, Sep 3, 2012 at 4:20 AM, Derick Rethans wrote: Ew, that's quite nasty (in both cases). Is there a way how we could turn those into a notice or so? cheers, Derick Sorry, hit reply instead of reply-all... list($a,$b) = 1; var_dump($a,$b); /* NUL

Re: [PHP-DEV] Foreach list behaviour

On Mon, Sep 3, 2012 at 4:20 AM, Derick Rethans wrote: > > Ew, that's quite nasty (in both cases). Is there a way how we could turn > those into a notice or so? > > cheers, > Derick > Sorry, hit reply instead of reply-all... list($a,$b) = 1; var_dump($a,$b); /* NULL NULL */ This doesn't throw no

Re: [PHP-DEV] RFC for Adding __toString to DateTime

hi! On Mon, Sep 3, 2012 at 6:28 PM, jpauli wrote: > Just In Case, I implemented a solution in an extension of mine. > I use a INI setting, ideas are on my github > https://github.com/jpauli/Comuto/blob/master/comuto.c#L97 and > https://github.com/jpauli/Comuto/blob/master/comuto.c#L175 > > Anyway

Re: [PHP-DEV] RFC for Adding __toString to DateTime

Just In Case, I implemented a solution in an extension of mine. I use a INI setting, ideas are on my github https://github.com/jpauli/Comuto/blob/master/comuto.c#L97 and https://github.com/jpauli/Comuto/blob/master/comuto.c#L175 Anyway, I'm really +1 for patching ext/date to add such a feature :)

Re: [PHP-DEV] $obj->attr::method() is not allowed

On 03/09/12 17:17, Laruence wrote: On Tue, Sep 4, 2012 at 12:05 AM, Andrew Faulds wrote: On 03/09/12 17:03, Laruence wrote: It is great parser(simple and fast) which make php works well for years.. No, it's not, it's overly complex. You have to define all sorts of different expression and var

Re: [PHP-DEV] $obj->attr::method() is not allowed

We have some RFC for parser rewrite using lemon : https://wiki.php.net/rfc/lemon And AFAIR, adoy has a full working rewrite just as-is, the main topic with lemon was to make the parser thread safe, not to generate an AST. Writing a parser / compiler for using an AST is a very huge task, so that m

Re: [PHP-DEV] $obj->attr::method() is not allowed

On Tue, Sep 4, 2012 at 12:05 AM, Andrew Faulds wrote: > On 03/09/12 17:03, Laruence wrote: >> >> It is great parser(simple and fast) which make php works well for years.. > > No, it's not, it's overly complex. You have to define all sorts of different > expression and variable variations :( if you

Re: [PHP-DEV] $obj->attr::method() is not allowed

On 03/09/12 17:03, Laruence wrote: It is great parser(simple and fast) which make php works well for years.. No, it's not, it's overly complex. You have to define all sorts of different expression and variable variations :( rewrite the parser for what? for more academism? No, because current o

Re: [PHP-DEV] $obj->attr::method() is not allowed

On Mon, Sep 3, 2012 at 11:18 PM, Andrew Faulds wrote: > On 03/09/12 15:51, Ivan Enderlin @ Hoa wrote: >> >> >> I would like to know why? Is it a compiler related issue or just an >> omission? Would it be interesting to fix it? >> > There are plenty of examples of this. One from my code: > > Can't

Re: [PHP-DEV] $obj->attr::method() is not allowed

On 03/09/12 17:20, Andrew Faulds wrote: On 03/09/12 16:20, Ivan Enderlin @ Hoa wrote: Absolutely. PHP has no AST? Why? For historical reasons? I believe so. Rasmus's original parser was not exactly world-class ;) Haha, ok ;-). Thanks. I thought it was a compiler related issue, now I am sur

Re: [PHP-DEV] $obj->attr::method() is not allowed

On 03/09/12 16:20, Ivan Enderlin @ Hoa wrote: Absolutely. PHP has no AST? Why? For historical reasons? I believe so. Rasmus's original parser was not exactly world-class ;) -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http:/

Re: [PHP-DEV] $obj->attr::method() is not allowed

On 03/09/12 17:18, Andrew Faulds wrote: On 03/09/12 15:51, Ivan Enderlin @ Hoa wrote: I would like to know why? Is it a compiler related issue or just an omission? Would it be interesting to fix it? There are plenty of examples of this. One from my code: Can't do this: self::$views[$

Re: [PHP-DEV] $obj->attr::method() is not allowed

On 03/09/12 15:51, Ivan Enderlin @ Hoa wrote: I would like to know why? Is it a compiler related issue or just an omission? Would it be interesting to fix it? There are plenty of examples of this. One from my code: Can't do this: self::$views[$path](); But I *can* do this: $x = s

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Mon, 3 Sep 2012, Benjamin Eberlei wrote: > as i said above, a global option will make this feature completly unusable > for libraries. For Doctrine we would really like to have __toString() for > datetime primary keys (identity map), but we need a reliable stable > lossless format that can nev

[PHP-DEV] $obj->attr::method() is not allowed

Hello, I would like to start with an example: a = new A(); } public function a ( ) { return $this->a; } public function f ( ) { return $this->a::foo(); } } $b = new B(); var_dump($b->f()); This is not possible. We

Re: [PHP-DEV] RFC for Adding __toString to DateTime

Will Fitch wrote: Hi, Lester - I'll update the patch and RFC to include this format. This is the format I'll use unless others have a better approach: 2012-09-01T00:00:00-0500 (America/Chicago) Either offset OR timezone ... not both ... BUT as Derick has pointed out ... without the offset,

Re: [PHP-DEV] RFC for Adding __toString to DateTime

Hi Will, Am 03.09.2012 um 15:04 schrieb Will Fitch : [...] > > > Hi, Lester - I'll update the patch and RFC to include this format. This is > the format I'll use unless others have a better approach: > > 2012-09-01T00:00:00-0500 (America/Chicago) Psst ... microseconds ... pssst. Please includ

Re: [PHP-DEV] RFC for Adding __toString to DateTime

as i said above, a global option will make this feature completly unusable for libraries. For Doctrine we would really like to have __toString() for datetime primary keys (identity map), but we need a reliable stable lossless format that can never change. On Mon, Sep 3, 2012 at 2:01 PM, Will Fitc

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On 3 September 2012 19:54, Will Fitch wrote: > On Mon, Sep 3, 2012 at 5:45 AM, Adam Harvey wrote: >> I just don't see how we can choose a sensible default format for >> users. Sometimes you want ISO 8601. Sometimes you want whatever your >> locale's customary date format is. Sometimes you want US

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Mon, 3 Sep 2012, Will Fitch wrote: > On Mon, Sep 3, 2012 at 8:09 AM, Lars Strojny wrote: > > > Additionally to what Ryan proposed, microseconds should be part of it > > (which ISO allows). So, here we go: > > > > 2012-09-02T18:17:36.12345+0100 (Europe/London) > > Hi Lars - there wouldn't b

Re: [PHP-DEV] Re: Are exceptions allowed in php core?

Em 2012-09-03 13:16, Derick Rethans escreveu: I think the first thing anyone who uses generators must understand is that they are iterators. You forget that not even everybody that uses PHP knows what an iterator is. For all they care, they have an array they can run foreach() on. They sho

Re: [PHP-DEV] RFC for Adding __toString to DateTime

hi Lars, On Mon, Sep 3, 2012 at 2:09 PM, Lars Strojny wrote: > Ease debugging by allowing "echo $date;" instead of "echo > $date->format(...);" Ooch. If that's the only goal, it makes no sense to add that. However I see many useful usages like passing date object to templates and the likes

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Mon, Sep 3, 2012 at 8:28 AM, Lester Caine wrote: > Derick Rethans wrote: > >> You have an accurate representation of the ISO format - which does not >>> >specify the string representation of a timezone, but rather the offset >>> of >>> >UTC. This is not lossy. >>> >> Yes it is! You can't go b

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Mon, Sep 3, 2012 at 8:09 AM, Lars Strojny wrote: > Hi Pierre, hi Will, > > Am 03.09.2012 um 13:57 schrieb Pierre Joye : > > > hi Will, > > > > On Mon, Sep 3, 2012 at 1:51 PM, Will Fitch wrote: > >> On Mon, Sep 3, 2012 at 4:59 AM, Ryan McCue wrote: > >> > >>> As far as I can tell, there's no

Re: [PHP-DEV] Re: Support negative indexes for arrays and strings

>as I understood, a lot of people seem to have problems with this proposal, >since arrays and strings could (and maybe >should) behave the same. The terminology "negative indexing" seems to imply that the feature should work with arrays. To restrict it to just strings might involve creating a te

Re: [PHP-DEV] Re: Are exceptions allowed in php core?

Derick Rethans wrote: I think the first thing anyone who uses generators must understand is that >they are iterators. You forget that not even everybody that uses PHP knows what an iterator is. For all they care, they have an array they can run foreach() on. >They should be compared with itera

Re: [PHP-DEV] RFC for Adding __toString to DateTime

Derick Rethans wrote: You have an accurate representation of the ISO format - which does not >specify the string representation of a timezone, but rather the offset of >UTC. This is not lossy. Yes it is! You can't go back from an UTC offset to a timezone string. Hence: lossy. Exactly ... Wil

Re: [PHP-DEV] RFC for Adding __toString to DateTime

Hi Will, Am 03.09.2012 um 14:01 schrieb Will Fitch : > On Mon, Sep 3, 2012 at 7:57 AM, Pierre Joye wrote: [...] > I actually feel a static function which tracks globally would best serve > this case: > > date_default_format_set('c') > > This would prevent the need for setting it on a per insta

Re: [PHP-DEV] RFC for Adding __toString to DateTime

Hi Pierre, hi Will, Am 03.09.2012 um 13:57 schrieb Pierre Joye : > hi Will, > > On Mon, Sep 3, 2012 at 1:51 PM, Will Fitch wrote: >> On Mon, Sep 3, 2012 at 4:59 AM, Ryan McCue wrote: >> >>> As far as I can tell, there's no standard which uses the Olson database >>> to specify the timezone, so

Re: [PHP-DEV] Foreach list behaviour

Laruence wrote: >Hi: > if we fixed this, what about following example: > > >$num = NULL; > >echo $num["xxx"]; > > > does this also deserve a notice? > >thanks No because NULL is just the first element in implicit array conversion > > > >-- >Laruence Xinchen Hui >http://www.laruence.com/

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Mon, Sep 3, 2012 at 7:57 AM, Pierre Joye wrote: > hi Will, > > On Mon, Sep 3, 2012 at 1:51 PM, Will Fitch wrote: > > On Mon, Sep 3, 2012 at 4:59 AM, Ryan McCue wrote: > > > >> As far as I can tell, there's no standard which uses the Olson database > >> to specify the timezone, so we'd have t

Re: [PHP-DEV] RFC for Adding __toString to DateTime

hi Will, On Mon, Sep 3, 2012 at 1:51 PM, Will Fitch wrote: > On Mon, Sep 3, 2012 at 4:59 AM, Ryan McCue wrote: > >> As far as I can tell, there's no standard which uses the Olson database >> to specify the timezone, so we'd have to create one. >> >> What about ISO8601 with the Olson timezone suf

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Mon, Sep 3, 2012 at 5:45 AM, Adam Harvey wrote: > On 3 September 2012 17:36, Andrew Faulds wrote: > > Ryan McCue wrote: > >>What about ISO8601 with the Olson timezone suffixed? > >> > >>2012-09-02T18:17:36+0100 (Europe/London) > >>2012-09-02T18:19:05+0100 (Africa/Niamey) > >> > > > >

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Mon, 3 Sep 2012, Will Fitch wrote: > You have an accurate representation of the ISO format - which does not > specify the string representation of a timezone, but rather the offset of > UTC. This is not lossy. Yes it is! You can't go back from an UTC offset to a timezone string. Hence: lossy

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Mon, Sep 3, 2012 at 4:59 AM, Ryan McCue wrote: > As far as I can tell, there's no standard which uses the Olson database > to specify the timezone, so we'd have to create one. > > What about ISO8601 with the Olson timezone suffixed? > > 2012-09-02T18:17:36+0100 (Europe/London) > 2012-0

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Mon, Sep 3, 2012 at 4:16 AM, Derick Rethans wrote: > On Sun, 2 Sep 2012, Will Fitch wrote: > > > 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 onl

[PHP-DEV] VCS Account Rejected: riad rejected by bjori

Nuked riad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Are exceptions allowed in php core?

On Sun, 2 Sep 2012, Gustavo Lopes wrote: > On Sun, 02 Sep 2012 02:27:02 +0200, Rasmus Lerdorf wrote: > > > $things = getStuff(); > > foreach($things as $thing) { > >do_some($thing); > > } > > > > which is very normal PHP that you see in millions of lines of code, I > > would not expect t

RE: [PHP-DEV] Support negative indexes for arrays and strings

Hi, Instead of [], which is ambiguous, couldn't we just extend the {} syntax : we already have $a{} working with positive numbers, couldn't we extend it to accept negative offsets also ? François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Mon, 3 Sep 2012, Adam Harvey wrote: > On 3 September 2012 17:36, Andrew Faulds wrote: > > Ryan McCue wrote: > >>What about ISO8601 with the Olson timezone suffixed? > >> > >>2012-09-02T18:17:36+0100 (Europe/London) > >>2012-09-02T18:19:05+0100 (Africa/Niamey) > >> > > > > Sounds good.

Re: [PHP-DEV] RFC for Adding __toString to DateTime

Best solution from a random developers perspective: - stick the 4-line solution in the docs and on to the bug report. Then mark as won't implement It's a far better solution than choosing a random format for users, as should be more than evident by now. Regards Peter -- WWW: plphp.dk / plind.d

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On 3 September 2012 17:36, Andrew Faulds wrote: > Ryan McCue wrote: >>What about ISO8601 with the Olson timezone suffixed? >> >>2012-09-02T18:17:36+0100 (Europe/London) >>2012-09-02T18:19:05+0100 (Africa/Niamey) >> > > Sounds good. If we're going to invent arbitrary non-standard formats,

Re: [PHP-DEV] RFC for Adding __toString to DateTime

Ryan McCue wrote: >As far as I can tell, there's no standard which uses the Olson database >to specify the timezone, so we'd have to create one. > >What about ISO8601 with the Olson timezone suffixed? > >2012-09-02T18:17:36+0100 (Europe/London) >2012-09-02T18:19:05+0100 (Africa/Niamey)

Re: [PHP-DEV] Foreach list behaviour

On Mon, Sep 3, 2012 at 5:28 PM, Pierre Joye wrote: > hi, > > On Mon, Sep 3, 2012 at 10:36 AM, Laruence wrote: >> On Mon, Sep 3, 2012 at 4:20 PM, Derick Rethans wrote: >>> On Mon, 3 Sep 2012, Laruence wrote: >>> On Mon, Sep 3, 2012 at 7:07 AM, Jared Williams wrote: > >

Re: [PHP-DEV] Release scheduling, branching & NEWS for 5.4

Pierre Joye wrote: >And no BC in 5.5 as well. Which will cause us some issue for 5.5 as >master actually has BC breaks as far as I remember. > Yep. My Logo GUIDs patch removed the functions to get the GUIDs, for instance. (although this is far from a serious breakage, images can be removed or

Re: [PHP-DEV] Foreach list behaviour

hi, On Mon, Sep 3, 2012 at 10:36 AM, Laruence wrote: > On Mon, Sep 3, 2012 at 4:20 PM, Derick Rethans wrote: >> On Mon, 3 Sep 2012, Laruence wrote: >> >>> On Mon, Sep 3, 2012 at 7:07 AM, Jared Williams >>> wrote: >>> > >>> > Just looking at the foreach list behaviour and it does this..

Re: [PHP-DEV] RFC for Adding __toString to DateTime

As far as I can tell, there's no standard which uses the Olson database to specify the timezone, so we'd have to create one. What about ISO8601 with the Olson timezone suffixed? 2012-09-02T18:17:36+0100 (Europe/London) 2012-09-02T18:19:05+0100 (Africa/Niamey) -- Ryan McCue

Re: [PHP-DEV] Foreach list behaviour

On Mon, Sep 3, 2012 at 4:20 PM, Derick Rethans wrote: > On Mon, 3 Sep 2012, Laruence wrote: > >> On Mon, Sep 3, 2012 at 7:07 AM, Jared Williams >> wrote: >> > >> > Just looking at the foreach list behaviour and it does this... >> > >> > $i = [1, 2, 3]; >> > foreach($i as list($a, $b)) >>

Re: [PHP-DEV] Foreach list behaviour

On Mon, 3 Sep 2012, Laruence wrote: > On Mon, Sep 3, 2012 at 7:07 AM, Jared Williams > wrote: > > > > 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 > >

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Sun, 2 Sep 2012, Will Fitch wrote: > 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'

Re: [PHP-DEV] Re: Are exceptions allowed in php core?

hi! On Sun, Sep 2, 2012 at 1:04 AM, Stas Malyshev wrote: > 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 betwee

Re: [PHP-DEV] Release scheduling, branching & NEWS for 5.4

hi! On Sun, Sep 2, 2012 at 4:11 AM, Stas Malyshev wrote: > 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. Thanks for posting this clarification, always good to send reminders like that :-) > 4.

Re: [PHP-DEV] Re: [VOTE] Generators

hi Derick, On Sun, Sep 2, 2012 at 7:10 PM, Derick Rethans wrote: > 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 mer

Re: [PHP-DEV] Re: Support negative indexes for arrays and strings

Am Sonntag, 2. September 2012 um 02:43 schrieb sle...@pipeline.com: > 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 stri