Re: [PHP-DEV] Consistent function names

On 3/11/2015 8:08 PM, Lester Caine wrote: Personally I just want to keep the current name set and so the sheer volume of changes proposed is a big kick in the face to me. YES! The time to make such a change to the names is about 1998 or maybe 2000. Every person who learns the current names i

Re: [PHP-DEV] static constructor

On Wed, Mar 11, 2015 at 6:10 PM, Rowan Collins wrote: > On 11/03/2015 23:21, Johannes Ott wrote: >> >> So now I want to do my first own proposal for a new function in PHP and >> I hope doing it right with starting a discussion here first. >> >> The purpose of this suggestion is to introduce a stat

Re: [PHP-DEV] Consistent function names

On 11/03/15 22:44, Yasuo Ohgaki wrote: > Having namespace for internals would bring much flexibility for API changes, > both > OO and procedural API. I may try my best to have consensus. > > I think you also like to have OO style API for basic > variables(int/float/array) as I am. > Unless we hav

Re: [PHP-DEV] Safe execution timeout handling

On Mar 11, 2015 7:01 PM, "Stas Malyshev" wrote: > > Hi! > > > Instead of throwing zend_error() from signal handler, now we just set > > EG(vm_interrupt) and EG(timed_out) flags. PHP VM checks EG(vm_interrupt) > > flag on each JMPx instruction (potential loop iteration) and then throws > > JMPs are

Re: [PHP-DEV] Safe execution timeout handling

Hi! > Instead of throwing zend_error() from signal handler, now we just set > EG(vm_interrupt) and EG(timed_out) flags. PHP VM checks EG(vm_interrupt) > flag on each JMPx instruction (potential loop iteration) and then throws JMPs are not the only operations that can transfer control and thus pot

Re: [PHP-DEV] static constructor

On 11/03/2015 23:21, Johannes Ott wrote: So now I want to do my first own proposal for a new function in PHP and I hope doing it right with starting a discussion here first. The purpose of this suggestion is to introduce a static constructor, which is called before the first call to class either

Re: [PHP-DEV] static constructor

Am 12.03.2015 um 00:30 schrieb Marco Pivetta: > Hey Johannes, > > Why can't this be done at autoloading time? In my opinion this should not be done on autoloading time, but as a own method inside the class for two reasons. 1. Not every class is loaded with autoload-functions, but although direct

Re: [PHP-DEV] static constructor

On 12 March 2015 at 00:21, Johannes Ott wrote: > The purpose of this suggestion is to introduce a static constructor, > which is called before the first call to class either static or > non-static to initialize some static properties which are needed by the > class. > Hey Johannes, Why can't th

[PHP-DEV] static constructor

So now I want to do my first own proposal for a new function in PHP and I hope doing it right with starting a discussion here first. The purpose of this suggestion is to introduce a static constructor, which is called before the first call to class either static or non-static to initialize some st

Re: [PHP-DEV] [RFC] Basic Scalar Types

Dmitry, I tend to disagree with many people wanting this over nothing. It's a big enough topic, that raised waives in the community, to be treated properly and not just throw it in before feature freeze, so I agree with Nikita on this one. My view on it is that if both RFC's fail, the feature sho

Re: [PHP-DEV] [RFC] Basic Scalar Types

On Thu, Mar 12, 2015 at 1:53 AM, Nikita Popov wrote: > On Wed, Mar 11, 2015 at 10:28 PM, Bob Weinand wrote: > > > Hi all, > > > > after all, some people are not happy with the current proposals about > > scalar types. So, they both still possibly may fail. > > > > Thus, I'd like to come up with

Re: [PHP-DEV] Safe execution timeout handling

On Thu, Mar 12, 2015 at 1:46 AM, Stanislav Malyshev wrote: > Hi! > > > I think, after "max_execution_time" is exceeded, we may start another > > "hard_timeout", and in case the EG(vm_interrupt) wasn't handled > > "safely", kill the process. > > I remember such proposal floating on the list recent

Re: [PHP-DEV] [RFC] Basic Scalar Types

On Wednesday, March 11, 2015, Bob Weinand wrote: >> Am 11.03.2015 um 23:29 schrieb Pavel Kouřil : >> It shouldn't prevent any future improvements and still give use all the >>> advantages of scalar types. >>> >>> Besides what I think of proposing yet another RFC, -1 because it is >>> basicall

Re: [PHP-DEV] [RFC] Basic Scalar Types

On Wed, Mar 11, 2015 at 10:28 PM, Bob Weinand wrote: > Hi all, > > after all, some people are not happy with the current proposals about > scalar types. So, they both still possibly may fail. > > Thus, I'd like to come up with a fallback proposal in case both proposals > fail: > > https://wiki.ph

Re: [PHP-DEV] Safe execution timeout handling

Hi! > I think, after "max_execution_time" is exceeded, we may start another > "hard_timeout", and in case the EG(vm_interrupt) wasn't handled > "safely", kill the process. I remember such proposal floating on the list recently, with two-stage timeouts. But wouldn't killing the process run the sam

Re: [PHP-DEV] [RFC] Basic Scalar Types

> Am 11.03.2015 um 23:23 schrieb Pierre Joye : > On Mar 12, 2015 8:30 AM, "Bob Weinand" > wrote: > > > > Hi all, > > > > after all, some people are not happy with the current proposals about > > scalar types. So, they both still possibly may fail. > > > > Thus, I'd lik

Re: [PHP-DEV] Consistent function names

Hi Rowan, On Wed, Mar 11, 2015 at 9:32 PM, Rowan Collins wrote: > Lester Caine wrote on 10/03/2015 21:12: > >> On 10/03/15 20:44, Yasuo Ohgaki wrote: >> >>> YES there is room to create a more consistent procedural interface, but > my original question still applies "consistent with what rule

Re: [PHP-DEV] [RFC] Basic Scalar Types

> Am 11.03.2015 um 23:29 schrieb Pavel Kouřil : > >>> It shouldn't prevent any future improvements and still give use all the >> advantages of scalar types. >> >> Besides what I think of proposing yet another RFC, -1 because it is >> basically what the initial idea from the opponents of optional

Re: [PHP-DEV] Safe execution timeout handling

On Thu, Mar 12, 2015 at 1:23 AM, Stanislav Malyshev wrote: > Hi! > > > Instead of throwing zend_error() from signal handler, now we just set > > EG(vm_interrupt) and EG(timed_out) flags. PHP VM checks EG(vm_interrupt) > > flag on each JMPx instruction (potential loop iteration) and then throws >

Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

Hi 2015-03-11 6:50 GMT-03:00 Patrick ALLAERT : > Le mar. 10 mars 2015 à 21:04, Marcio Almada a > écrit : > >> >> >> 2015-03-10 12:31 GMT-03:00 Patrick ALLAERT : >> >>> Hello, >>> >>> Le lun. 2 mars 2015 à 00:03, Marcio Almada a >>> écrit : >>> >>> >>> I'm globally +0.5, however I have some con

Re: [PHP-DEV] [RFC] Basic Scalar Types

>> It shouldn't prevent any future improvements and still give use all the > advantages of scalar types. > > Besides what I think of proposing yet another RFC, -1 because it is > basically what the initial idea from the opponents of optional strict mode > wanted before they go with the latest one.

Re: [PHP-DEV] [RFC] Basic Scalar Types

On Mar 12, 2015 8:30 AM, "Bob Weinand" wrote: > > Hi all, > > after all, some people are not happy with the current proposals about scalar types. So, they both still possibly may fail. > > Thus, I'd like to come up with a fallback proposal in case both proposals fail: > > https://wiki.php.net/rfc/

Re: [PHP-DEV] Safe execution timeout handling

Hi! > Instead of throwing zend_error() from signal handler, now we just set > EG(vm_interrupt) and EG(timed_out) flags. PHP VM checks EG(vm_interrupt) > flag on each JMPx instruction (potential loop iteration) and then throws That looks very nice but makes timeouts much less powerful. I think wit

Re: [PHP-DEV] [RFC] Basic Scalar Types

On 11 March 2015 at 14:28, Bob Weinand wrote: > after all, some people are not happy with the current proposals about scalar > types. So, they both still possibly may fail. > > Thus, I'd like to come up with a fallback proposal in case both proposals > fail: > > https://wiki.php.net/rfc/basic_sc

Re: [PHP-DEV] [RFC] Basic Scalar Types

Am 11.03.2015 um 22:28 schrieb Bob Weinand: > Hi all, > > after all, some people are not happy with the current proposals about scalar > types. So, they both still possibly may fail. > > Thus, I'd like to come up with a fallback proposal in case both proposals > fail: > > https://wiki.php.net/

Re: [PHP-DEV] [RFC] Basic Scalar Types

On Thu, Mar 12, 2015 at 12:28 AM, Bob Weinand wrote: > Hi all, > > after all, some people are not happy with the current proposals about > scalar types. So, they both still possibly may fail. > > Thus, I'd like to come up with a fallback proposal in case both proposals > fail: > > https://wiki.ph

[PHP-DEV] Safe execution timeout handling

Hi, Unsafe "max_execution_time" and "Out of Memory" handling is a huge problem, that often lead to crashes and SHM corruption. The PoC solves the first problem. https://github.com/php/php-src/pull/1173 Instead of throwing zend_error() from signal handler, now we just set EG(vm_interrupt) and EG

Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

2015-03-11 6:27 GMT-03:00 Lester Caine : > On 11/03/15 09:05, wp12173047-156224 wp12173047-156224 wrote: > >>> BTW, the current PHP silent behavior should be considered even more > >>> > > confusing otherwise we > >>> > > wouldn't have these measurements: > >>> > > > >>> > > > https://wiki.php.net

Re: [PHP-DEV] Request Feedback for Instance Variable Sugar RFC

Am 11.03.2015 um 18:12 schrieb Rowan Collins: > Johannes Ott wrote on 11/03/2015 16:46: >> Am 11.03.2015 um 17:21 schrieb Rowan Collins: >> >>> My reasoning is that code that is ambiguous is hard to read. If "$foo" >>> can mean either "a local variable called $foo" or "a property of the >>> current

[PHP-DEV] RE: [VOTE][RFC] Coercive Scalar Type Hints

> -Original Message- > From: Zeev Suraski [mailto:z...@zend.com] > Sent: Wednesday, March 11, 2015 11:28 PM > To: 'Theodore Brown' > Cc: 'internals@lists.php.net' > Subject: RE: [VOTE][RFC] Coercive Scalar Type Hints > > Yes, with strict STH you'd know that more things fail during static an

[PHP-DEV] [RFC] Basic Scalar Types

Hi all, after all, some people are not happy with the current proposals about scalar types. So, they both still possibly may fail. Thus, I'd like to come up with a fallback proposal in case both proposals fail: https://wiki.php.net/rfc/basic_scalar_types It shouldn't prevent any future improve

[PHP-DEV] RE: [VOTE][RFC] Coercive Scalar Type Hints

> -Original Message- > From: Theodore Brown [mailto:theodor...@outlook.com] > Sent: Wednesday, March 11, 2015 11:01 PM > To: Zeev Suraski > Cc: internals@lists.php.net > Subject: RE: [VOTE][RFC] Coercive Scalar Type Hints > > On Wednesday, March 11 2015 at 1:14 pm Zeev Suraski wrote: > > >

Re: [PHP-DEV] Re: Introduce DerOetzi

Am 11.03.2015 um 15:05 schrieb Niklas Keller: > You have to input "internals@lists.php.net", that changed some time ago. > I've just updated https://wiki.php.net/rfc/howto > See > https://github.com/php/web-wiki/commit/583d2c1b39a8b88960ab94e56ba4a4608ddb2353 > > Regards, Niklas > Thanks that he

Re: [PHP-DEV] RE: [VOTE][RFC] Coercive Scalar Type Hints

Zeev, On Wed, Mar 11, 2015 at 4:50 PM, Zeev Suraski wrote: >> -Original Message- >> From: Derick Rethans [mailto:der...@php.net] >> Sent: Wednesday, March 11, 2015 10:37 PM >> To: Zeev Suraski >> Cc: Anthony Ferrara; internals@lists.php.net >> Subject: RE: [PHP-DEV] RE: [VOTE][RFC] Coerci

[PHP-DEV] RE: [VOTE][RFC] Coercive Scalar Type Hints

On Wednesday, March 11 2015 at 1:14 pm Zeev Suraski wrote: > I don't believe strict STH would bring any meaningful gains for static > analysis, no. Unlike the JIT/AOT advantages (on the same code) which I > believe I've proven cannot be gained, I can't prove this one - because you > can infer slig

RE: [PHP-DEV] RE: [VOTE][RFC] Coercive Scalar Type Hints

> -Original Message- > From: Derick Rethans [mailto:der...@php.net] > Sent: Wednesday, March 11, 2015 10:37 PM > To: Zeev Suraski > Cc: Anthony Ferrara; internals@lists.php.net > Subject: RE: [PHP-DEV] RE: [VOTE][RFC] Coercive Scalar Type Hints > > > You're right, sorry. Reverse it then: >

RE: [PHP-DEV] RE: [VOTE][RFC] Coercive Scalar Type Hints

On Wed, 11 Mar 2015, Zeev Suraski wrote: > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > > > > function bar(float $x) > > > $foo = 1; > > > bar($foo); // will definitely fail in strict mode > > > > No, actually it won't fail in strict mode: > > https://wiki.php.net/rfc/scalar_type_hints_v5

Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

On Mar 12, 2015 2:10 AM, "Zeev Suraski" wrote: > > The vote on the Coercive Scalar Type Hints is now open for voting. > > > > The latest version of the RFC includes changes discussed on internals@ last > week: > > 1. Accept string->bool and int->bool conversions (false->bool is not > supported) >

Re: [PHP-DEV] Re: [VOTE][RFC] Coercive Scalar Type Hints

On 11 March 2015 at 18:46, Eli wrote: > Benoit ... actually Anthony's original proposal specifically was > designed to be live at the same time as this alternative proposal. And > it's even mentioned in the proposal (stating that it would stay open > until the 13th or when the alternative proposa

[PHP-DEV] Re: [VOTE][RFC] Coercive Scalar Type Hints

Hi, You are making a very huge mistake, IMHO. By having 2 conflicting RFC, you are taking the risk they both fail. And it won't do any good to the language. While you could have either proposed yours after the STH one if it would have failed, or create a new RFC to make the STH one evolve if it

RE: [PHP-DEV] RE: [VOTE][RFC] Coercive Scalar Type Hints

> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Wednesday, March 11, 2015 8:28 PM > To: Zeev Suraski > Cc: Theodore Brown; internals@lists.php.net > Subject: Re: [PHP-DEV] RE: [VOTE][RFC] Coercive Scalar Type Hints > > Zeev, > > >> You also stated above tha

RE: [PHP-DEV] Re: [VOTE][RFC] Coercive Scalar Type Hints

It was actually Anthony who proposed that I do that. He also proposed that if they both pass, we'll have a vote to choose between them. For a lot of people, the dual mode and coercive STH RFCs aren't a zero sum game. They just want ONE of them to pass to have some sort of scalar type hinting, an

Re: [PHP-DEV] Re: [VOTE][RFC] Coercive Scalar Type Hints

Benoit ... actually Anthony's original proposal specifically was designed to be live at the same time as this alternative proposal. And it's even mentioned in the proposal (stating that it would stay open until the 13th or when the alternative proposal voting ended - whichever was later) So this

Re: [PHP-DEV] RE: [VOTE][RFC] Coercive Scalar Type Hints

Zeev, >> You also stated above that false->bool is not supported (I'm guessing > you >> meant float->bool). So users would be able to pass "4.3" to a bool > typehint, >> but not 4.3? This behavior seems very arbitrary and confusing. > > It may be confusing, but only academically so. Again, this a

RE: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

> -Original Message- > From: Dan Ackroyd [mailto:dan...@basereality.com] > Sent: Wednesday, March 11, 2015 8:04 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints > > On 11 March 2015 at 16:45, Zeev Suraski wrote: > > I think that goin

[PHP-DEV] RE: [VOTE][RFC] Coercive Scalar Type Hints

> The proposed coercion rules aren't clear. The first table in the RFC implies > that string is accepted for bool hints, and the second table says this is > unchanged. But the examples section states that "foo" -> bool will raise an > E_DEPRECATED error. I'm guessing this is a mistake, since you me

Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

On 11 March 2015 at 16:45, Zeev Suraski wrote: > I think that going through a transition period ... that ultimately results > in one, consistent language behavior This RFC is explicitly saying that there is stuff that will be need to be changed in the future. Why would anyone upgrade from PHP 5.6

Re: [PHP-DEV][RFC][VOTING] Context Sensitive Lexer

Hi, 2015-03-11 11:49 GMT-03:00 Nikita Popov : > On Mon, Mar 9, 2015 at 6:47 AM, Marcio Almada > wrote: > >> Hi, >> >> Just passing by to announce I already have a working version of the new >> patch: https://github.com/php/php-src/pull/1158 >> >> The patch is 100% compatible with the proposed on

Re: [PHP-DEV][RFC][VOTING] Context Sensitive Lexer

On Wed, Mar 11, 2015 at 5:49 PM, Nikita Popov wrote: > On Mon, Mar 9, 2015 at 6:47 AM, Marcio Almada > wrote: > > > Hi, > > > > Just passing by to announce I already have a working version of the new > > patch: https://github.com/php/php-src/pull/1158 > > > > The patch is 100% compatible with th

Re: [PHP-DEV] Request Feedback for Instance Variable Sugar RFC

Johannes Ott wrote on 11/03/2015 16:46: Am 11.03.2015 um 17:21 schrieb Rowan Collins: My reasoning is that code that is ambiguous is hard to read. If "$foo" can mean either "a local variable called $foo" or "a property of the current object called $foo", then you have to know which it is in ord

[PHP-DEV] Re: [VOTE][RFC] Coercive Scalar Type Hints

Zeev, > The vote on the Coercive Scalar Type Hints is now open for voting. > > The latest version of the RFC includes changes discussed on internals@ last > week: > > 1.  Accept string->bool and int->bool conversions (false->bool is not > supported) > 2.  Accept leading/trailing spaces in string

RE: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

> -Original Message- > From: Dan Ackroyd [mailto:dan...@basereality.com] > Sent: Wednesday, March 11, 2015 5:53 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints > > Voting no due to: > > i) Having conversion rules be difference in use

Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

Hi, Derick Rethans writes: > On Wed, 11 Mar 2015, Zeev Suraski wrote: > >> The vote on the Coercive Scalar Type Hints is now open for voting. >> >> >> >> The latest version of the RFC includes changes discussed on internals@ last >> week: >> >> 1. Accept string->bool and int->bool conversions (

Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

All, On Wed, Mar 11, 2015 at 11:52 AM, Dan Ackroyd wrote: > Voting no due to: > > i) Having conversion rules be difference in userland to internal functions. > > You list 'Single Mode' as a benefit of this RFC, but it's only single > mode if you gloss over this difference. This is a massive cogni

RE: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

> -Original Message- > From: Derick Rethans [mailto:der...@php.net] > Sent: Wednesday, March 11, 2015 5:57 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints > > On Wed, 11 Mar 2015, Zeev Suraski wrote: > Aren't you supposed to leave it

Re: [PHP-DEV] Request Feedback for Instance Variable Sugar RFC

Johannes Ott wrote on 11/03/2015 13:36: Am 11.03.2015 um 14:03 schrieb Rowan Collins: Johannes Ott wrote on 10/03/2015 20:46: okay indeed the dynamic properties are a problem I didn't think about on my suggestion. Without the wish to hijack this thread for another typesafety discussion, I must

RE: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

Anthony, While I only put in the final changes today, they're identical to what I said was going to be done on the discussion thread a week+ ago, there was no further feedback or discussion on these changes. The patch (minus these two minor changes) has been available for over a week. I think we'

Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

On Wed, 11 Mar 2015, Zeev Suraski wrote: > The vote on the Coercive Scalar Type Hints is now open for voting. > > > > The latest version of the RFC includes changes discussed on internals@ last > week: > > 1. Accept string->bool and int->bool conversions (false->bool is not > supported) > >

Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

Zeev, Considering that there has not been any discussion of your final proposal (since the last change), I think putting it to vote prior to having the ability to test or discuss is extremely problematic. Especially considering every time we tried to test the proposal or discuss it before you said

[PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

The vote on the Coercive Scalar Type Hints is now open for voting. The latest version of the RFC includes changes discussed on internals@ last week: 1. Accept string->bool and int->bool conversions (false->bool is not supported) 2. Accept leading/trailing spaces in string->number conversions

Re: [PHP-DEV][RFC][VOTING] Context Sensitive Lexer

On Mon, Mar 9, 2015 at 6:47 AM, Marcio Almada wrote: > Hi, > > Just passing by to announce I already have a working version of the new > patch: https://github.com/php/php-src/pull/1158 > > The patch is 100% compatible with the proposed one with the advantages: > >- Has no regression or forwar

[PHP-DEV] Re: Introduce DerOetzi

Am 11.03.2015 um 14:25 schrieb Christoph Becker: > Johannes Ott wrote: > >> BTW: >> >> I'm trying to register a wiki account. But somehow it does not work. >> >> When posting the formular the page is reloading, but nothing else >> happens. No success or no error message is shown. >> >> Maybe I'm d

[PHP-DEV] Re: Introduce DerOetzi

Johannes Ott wrote: > BTW: > > I'm trying to register a wiki account. But somehow it does not work. > > When posting the formular the page is reloading, but nothing else > happens. No success or no error message is shown. > > Maybe I'm doing something wrong?! Maybe you have not filled out the

Re: [PHP-DEV] Request Feedback for Instance Variable Sugar RFC

Johannes Ott wrote on 10/03/2015 20:46: okay indeed the dynamic properties are a problem I didn't think about on my suggestion. Without the wish to hijack this thread for another typesafety discussion, I must say again that PHP needs a less dynamic and more declaratively properties concept in my

Re: [PHP-DEV] [VOTE] [RFC] continue output buffering

On Wed, Mar 11, 2015 at 12:09 PM, Patrick ALLAERT wrote: > Le lun. 9 mars 2015 à 13:45, Michael Wallner a écrit : > > > Hi, I’d like to start vote on RFC:continue_ob — any objections? > > > > https://wiki.php.net/rfc/continue_ob < > https://wiki.php.net/rfc/continue_ob > > > > > > > Regards, > >

[PHP-DEV] Re: Introduce DerOetzi

BTW: I'm trying to register a wiki account. But somehow it does not work. When posting the formular the page is reloading, but nothing else happens. No success or no error message is shown. Maybe I'm doing something wrong?! Regards -- DerOetzi -- PHP Internals - PHP Runtime Development Mailin

Re: [PHP-DEV] Consistent function names

On 11/03/15 12:32, Rowan Collins wrote: > Lester Caine wrote on 10/03/2015 21:12: >> On 10/03/15 20:44, Yasuo Ohgaki wrote: > YES there is room to create a more consistent procedural interface, > but > my original question still applies "consistent with what rules?" >>> It's possible ch

Re: [PHP-DEV] Consistent function names

Lester Caine wrote on 10/03/2015 21:12: On 10/03/15 20:44, Yasuo Ohgaki wrote: YES there is room to create a more consistent procedural interface, but my original question still applies "consistent with what rules?" It's possible choice. I agree that names without "_" looks more consistent. Per

Re: [PHP-DEV] [VOTE] [RFC] continue output buffering

Le lun. 9 mars 2015 à 13:45, Michael Wallner a écrit : > Hi, I’d like to start vote on RFC:continue_ob — any objections? > > https://wiki.php.net/rfc/continue_ob > > > Regards, > Mike > No objections. It didn't really require an RFC IMO, but it doesn't hu

Re: [PHP-DEV] [RFC] Anonymous Classes

Hi Phil. I really like this feature and am keen to see it go in. Developers often create classes (which are typically new files) just to extend and implement a small method. This feature could see codebases become much lighter. So a massive thanks for your and Joe’s efforts on this. I have tw

Re: [PHP-DEV] Lists: a simple way to improve PHP performance

That's a good question, I never tried the SPL library. But if we're to stick to whatever information is readily available, it's not good enough, as Spl seems to be 15-30% faster when I'm looking for 10x faster - however I'm looking at a really specific portion of performance which would probably b

Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

On 11/03/15 09:05, wp12173047-156224 wp12173047-156224 wrote: >>> BTW, the current PHP silent behavior should be considered even more >>> > > confusing otherwise we >>> > > wouldn't have these measurements: >>> > > >>> > > https://wiki.php.net/rfc/strict_argcount#bc_breaks_on_the_real_world >> >

Re: [PHP-DEV] Lists: a simple way to improve PHP performance

Isn’t this already implemented in the SPL library? http://php.net/manual/en/spl.datastructures.php -- Met vriendelijke groet, Camilo Sperberg Sent with Airmail On 11 Mar 2015 at 10:15:11, Ludovic Urbain (m...@ludovicurbain.com) wrote: > Hello, > > > I've been working with PHP for a while an

[PHP-DEV] Lists: a simple way to improve PHP performance

Hello, I've been working with PHP for a while and it's always sad to see array()'s performance being so terrible, in so many cases where a simple list would have done the trick without any slowdown. So why don't we add a basic list type to PHP ? There's nothing to lose, everything to gain, and

[PHP-DEV] Re: Voting choice for language changes (Was: "Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count")

Le mar. 10 mars 2015 à 19:29, Marcio Almada a écrit : > Hi, > > 2015-03-10 11:39 GMT-03:00 Patrick ALLAERT : > > Hello, >> >> Le ven. 6 mars 2015 à 00:44, Marcio Almada a >> écrit : >>> >>> You are right about this. I'll setup a yes/no vote + a vote to decide >>> between E_WARNING (for consisten

Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

Hi Stas, > Stanislav Malyshev hat am 11. März 2015 um 05:49 > geschrieben: > > > Hi! > > > related to the proposed RFC. *But* after some heuristics it was > > noticeable that most warnings had a common cause. I parsed the output > > It doesn't matter if it has common cause or not. If I have a

Re: [PHP-DEV] [VOTE] [RFC] continue output buffering

Hi all! > On 11 03 2015, at 08:26, Matteo Beccati wrote: > > On 10/03/2015 03:10, Yasuo Ohgaki wrote: >> Hi Mike, >> >> On Mon, Mar 9, 2015 at 9:45 PM, Michael Wallner wrote: >> >>> Hi, I’d like to start vote on RFC:continue_ob — any objections? >>> >>> https://wiki.php.net/rfc/continue_ob <

Re: [PHP-DEV] [VOTE] [RFC] continue output buffering

On 10/03/2015 03:10, Yasuo Ohgaki wrote: Hi Mike, On Mon, Mar 9, 2015 at 9:45 PM, Michael Wallner wrote: Hi, I’d like to start vote on RFC:continue_ob — any objections? https://wiki.php.net/rfc/continue_ob