Re: [PHP-DEV] Assess acceptability of having php-ds into core

Hi On May 13, 2016 8:28 AM, "guilhermebla...@gmail.com" < guilhermebla...@gmail.com> wrote: > > Hi internals, > > PHP 7 leverages a lot the performance internally and many PHP applications > in the wild. Much of these improvement came by experimentation through > PHPNG and the usage of efficient

Re: [PHP-DEV] Assess acceptability of having php-ds into core

On Thu, May 12, 2016 at 7:27 PM, guilhermebla...@gmail.com wrote: > Hi internals, > > PHP 7 leverages a lot the performance internally and many PHP applications > in the wild. Much of these improvement came by experimentation through > PHPNG and the usage of efficient

Re: [PHP-DEV] Functorial interfaces

Hi! > The PHP manual says, regarding Interfaces, that the class implementing > the interface must use the exact same method signatures as are defined > in the interface. Not doing so will result in a fatal error. I think this is mainly for practical reasons - when you compile class Bar, you may

Re: [PHP-DEV] [RFC] [Discussion] Third-party editing of RFCs

On Thu, May 12, 2016 at 4:37 PM, Stanislav Malyshev wrote: >> https://wiki.php.net/rfc/rfc.third-party-editing >> >> Let's make RFCs more useful before AND after voting! > > I like the idea, though I would suggest some limit on how big each > argument should be (maybe

[PHP-DEV] Assess acceptability of having php-ds into core

Hi internals, PHP 7 leverages a lot the performance internally and many PHP applications in the wild. Much of these improvement came by experimentation through PHPNG and the usage of efficient data structures internally. This idea of performance improvements are crucial to handle more requests,

Re: [PHP-DEV] [RFC] [Discussion] Third-party editing of RFCs

Hi! > https://wiki.php.net/rfc/rfc.third-party-editing > > Let's make RFCs more useful before AND after voting! I like the idea, though I would suggest some limit on how big each argument should be (maybe informal recommendation) to not turn that section into a copy of the ML discussion. --

Re: [PHP-DEV] [RFC] [Discussion] Third-party editing of RFCs

Sara Golemon wrote: https://wiki.php.net/rfc/rfc.third-party-editing Let's make RFCs more useful before AND after voting! I would hope it would effect the discussion for the positive as opinions wouldn't need to be restated over and over again, and when it comes times to vote, those doing

Re: [PHP-DEV] [RFC] [Discussion] Third-party editing of RFCs

On Thu, May 12, 2016 at 1:32 PM, Robert Williams wrote: > It reminds me of the election pamphlets that my state sends > out to inform voters of what the upcoming ballet measures are and what > various folks’ for/against arguments are. > I was literally looking at said

Re: [PHP-DEV] [RFC] Pipe Operator

On Thu, May 12, 2016 at 11:52 AM, François Laupretre wrote: > If we restrict usage to function calls, we can quite easily get rid of the $$ > by > associating to each function the position where the lhs must be inserted > when used as a 'piped function call'. > So we'd have to

[PHP-DEV] PHP 5.6.22 RC1 is available for testing

Hello everyone, PHP 5.6.22 RC1 was just released and can be downloaded from: http://downloads.php.net/~tyrael/ The Windows binaries are available at http://windows.php.net/qa/ This release contains a number of bugfixes. For the list of bugfixes that you can target in your testing, please refer

Re: [PHP-DEV] Functorial interfaces

On 12/05/2016 19:02, Rowan Collins wrote: On 12/05/2016 17:47, Andreas Heigl wrote: It's the other way around. The interface creates a contract that ensures that you can use ALL methods available in your SpecialClass. I don't think that's what the interface in the example means: interface

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

> What happens if you say <<$x>> and then call $reflection->getAttributes() in > your eample? what is $x? > > That is the problem with immediately evaluating everything non "constant". > There is no context. There's is no context. Annotations should be context-free - that's by design. There's

Re: [PHP-DEV] [RFC] [Discussion] Third-party editing of RFCs

This would be great if everyone just wanted to state their stance and be done with it. It reminds me of the election pamphlets that my state sends out to inform voters of what the upcoming ballet measures are and what various folks’ for/against arguments are. But those arguments are collected

Re: [PHP-DEV] Re: [RFC][VOTE] Nullable Types

On 05/12/2016 01:50 PM, Lester Caine wrote: > On 12/05/16 12:39, Michael Wallner wrote: >> On 12/05/16 13:36, Lester Caine wrote: On 12/05/16 11:21, Davey Shafik wrote: >> E.g. the behavior of passing executing with a null value for the >> argument is something you should be

Re: [PHP-DEV] Wiki RFC karma request: duncan3dc

On 4 January 2016 at 16:42, Craig Duncan wrote: > Hi, > > I'd like to create an RFC to change the behaviour of counting objects, as > discussed in the following pull request: > https://github.com/php/php-src/pull/1672 > > Please can I be granted rfc karma so I can create

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

On Thu, May 12, 2016 at 9:02 PM, Rasmus Schultz wrote: > My problem with this PSR is you've created something that strongly > resembles function or constructor calls, but in reality is just > key/value pairs. > Its actually function calls, not constructors calls :-) > >

Re: [PHP-DEV] [RFC] [Discussion] Third-party editing of RFCs

On Thu, May 12, 2016 at 12:33 PM, Sara Golemon wrote: > https://wiki.php.net/rfc/rfc.third-party-editing > > Let's make RFCs more useful before AND after voting! > Yes please! It certainly would make it far easier to see the arguments for and against and have a history of

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

My problem with this PSR is you've created something that strongly resembles function or constructor calls, but in reality is just key/value pairs. That's confusing in itself, but also puts an unnecessary burden on consumers who have to figure out how to map this apparently "something" to

Re: [PHP-DEV] [RFC] Pipe Operator

Hi Sara, Le 12/05/2016 à 19:02, Sara Golemon a écrit : On Thu, May 12, 2016 at 5:48 AM, Zeev Suraski wrote: Whether it's $$ or !# or $0 or any other random symbol doesn't really matter. Agreed. Here we have a completely optional syntactic sugar, that's not nearly as widely

[PHP-DEV] Re: [RFC] Pipe Operator

On Fri, Apr 29, 2016 at 12:58 PM, Sara Golemon wrote: > This is one of my favorites out of HackLang. It's pure syntactic > sugar, but it goes a long way towards improving readability. > https://wiki.php.net/rfc/pipe-operator > I've added a summary (as best I see it) of

[PHP-DEV] [RFC] [Discussion] Third-party editing of RFCs

https://wiki.php.net/rfc/rfc.third-party-editing Let's make RFCs more useful before AND after voting! -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Functorial interfaces

On 12/05/2016 17:47, Andreas Heigl wrote: It's the other way around. The interface creates a contract that ensures that you can use ALL methods available in your SpecialClass. I don't think that's what the interface in the example means: interface Foo { public function foo(SpecialClass

Re: [PHP-DEV] [RFC] Pipe Operator

On Thu, May 12, 2016 at 5:48 AM, Zeev Suraski wrote: > Whether it's $$ or !# or $0 or any other random symbol doesn't really matter. > Agreed. > Here we have a completely optional syntactic sugar, > that's not nearly as widely useful as OOP or namespaces. > Very few things will be

Re: [PHP-DEV] [RFC] Pipe Operator

On Thu, May 12, 2016 at 5:33 AM, Quim Calpe wrote: > Is $0 being considered? It's not ideal but is used as "pattern match > reference" in preg_replace, so we have a (sort of) precedent here. Same for > $1 (first capturing subpattern). > I don't believe it's been brought up yet,

Re: [PHP-DEV] Functorial interfaces

Am 12.05.16 um 18:37 schrieb Marco Perone: > Hi everybody, > I hope this is the right place for asking such a question. If that's not > the case, please excuse me; I'd appreciate if you could redirect me to > the appropriate place. > > The PHP manual says, regarding Interfaces, that the class

[PHP-DEV] Functorial interfaces

Hi everybody, I hope this is the right place for asking such a question. If that's not the case, please excuse me; I'd appreciate if you could redirect me to the appropriate place. The PHP manual says, regarding Interfaces, that the class implementing the interface must use the exact same

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

On 12 May 2016 at 16:29, Benjamin Eberlei wrote: > On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov wrote: > > > Hi internals, > > > > > > I've started voting on "PHP Attributes" RFC. > > > > > > https://wiki.php.net/rfc/attributes > > > > > > In my opinion,

Re: [PHP-DEV] Re: [RFC][VOTE] Nullable Types

On 12/05/2016 14:46, Lester Caine wrote: The key element *I* of cause am miss reading is the (Bar ...) which is a type hint. That will not exist in any of the code prior to ? and that is the key to what is being discussed. No type hint ... no change? If someone 'improves' a third party library

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov wrote: > Hi internals, > > > I've started voting on "PHP Attributes" RFC. > > > https://wiki.php.net/rfc/attributes > > > In my opinion, "PHP Attributes" might be a smart tool for PHP extension, > but it's not going to be the end of

Re: [PHP-DEV] Re: [RFC][VOTE] Nullable Types

On 12/05/16 13:38, Rowan Collins wrote: > Now let's say the author of the something function decides to use the > new nullable type hint: > > function something(?Bar $bar) {} > something(new Bar); // OK > something(); // Error: Missing required parameter > something(null); // OK > > None of your

[PHP-DEV] Request for RFC karma

Hi, I'm writing to request for RFC karma. Here is what I am doing and why doing this. The pack/unpack's parameter 'd' and 'f' are machine order in PHP. The number 236.0 packed to 'd' is: 00806d40. I was reversing a game save file, which uses 406D8000. Here is how I decode that

Re: [PHP-DEV] [RFC] Pipe Operator

> On 12 במאי 2016, at 15:34, Quim Calpe wrote: > >> On Thu, May 12, 2016 at 12:33 PM, Davey Shafik wrote: >> >> On Thu, May 12, 2016 at 1:19 AM, Larry Garfield >> wrote: >> On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev

Re: [PHP-DEV] Re: [RFC][VOTE] Nullable Types

On 12/05/2016 12:36, Lester Caine wrote: On 12/05/16 11:21, Davey Shafik wrote: E.g. the behavior of passing executing with a null value for the argument is something you should be consciously making a decision on, and passing in null explicitly. I was actually getting the logic wrong... the

Re: [PHP-DEV] [RFC] Pipe Operator

On Thu, May 12, 2016 at 12:33 PM, Davey Shafik wrote: > On Thu, May 12, 2016 at 1:19 AM, Larry Garfield > wrote: > > > On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev wrote: > > > Hi! > > > > > > > |> seems like a common symbol to use, but it

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-05-12

Results for project PHP master, build date 2016-05-12 06:29:10+03:00 commit: 8a7a913 previous commit:1c49a9f revision date: 2016-05-12 00:44:18+03:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

Re: [PHP-DEV] Re: [RFC][VOTE] Nullable Types

On 12/05/16 12:39, Michael Wallner wrote: > On 12/05/16 13:36, Lester Caine wrote: >> > On 12/05/16 11:21, Davey Shafik wrote: >>> >> E.g. the behavior of passing executing with a null value for the >>> >> argument is something you should be consciously making a decision on, >>> >> and passing in

Re: [PHP-DEV] [RFC] Pipe Operator

Hi Larry, On Thu, May 12, 2016 at 8:19 AM, Larry Garfield wrote: > On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev wrote: >> Hi! >> >> > |> seems like a common symbol to use, but it admittedly does look a >> >> So, usage in one semi-obscure language (F#) and one

Re: [PHP-DEV] Re: [RFC][VOTE] Nullable Types

On 12/05/16 13:36, Lester Caine wrote: > On 12/05/16 11:21, Davey Shafik wrote: >> E.g. the behavior of passing executing with a null value for the >> argument is something you should be consciously making a decision on, >> and passing in null explicitly. > > I was actually getting the logic

Re: [PHP-DEV] Re: [RFC][VOTE] Nullable Types

On 12/05/16 11:21, Davey Shafik wrote: > E.g. the behavior of passing executing with a null value for the > argument is something you should be consciously making a decision on, > and passing in null explicitly. I was actually getting the logic wrong... the problem with this proposal is that I

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi Lester, On Thu, May 12, 2016 at 6:27 PM, Lester Caine wrote: > On 12/05/16 04:19, Yasuo Ohgaki wrote: >> It could be an option that abandon session module and let users to >> implement decent session manager because we are taking too long time >> even for mandatory things

Re: [PHP-DEV] [RFC] Pipe Operator

On Thu, May 12, 2016 at 1:19 AM, Larry Garfield wrote: > On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev wrote: > > Hi! > > > > > |> seems like a common symbol to use, but it admittedly does look a > > > > So, usage in one semi-obscure language (F#) and one

[PHP-DEV] PHP 7.0.7 RC1 is available for testing

Hi, PHP 7.0.7 RC1 was just released and can be downloaded from: https://downloads.php.net/~ab/ The Windows binaries are available at http://windows.php.net/qa/ This release contains a number of bugfixes. For the list of bugfixes that you can target in your testing, please refer to the

Re: [PHP-DEV] Re: [RFC][VOTE] Nullable Types

By removing the ?, the function doesn't fail because it can no longer handle a null, the _engine_ throws an error because you're no longer allowed to _pass_ a null, it doesn't even execute the function itself. If you were to either a) define it as ?Foo $foo = null in the first place, or b) change

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

On 12/05/16 04:19, Yasuo Ohgaki wrote: > It could be an option that abandon session module and let users to > implement decent session manager because we are taking too long time > even for mandatory things even if there are implementations. It is > simply taking too long time to fix them. I'm

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

On 11/05/2016 13:29, Rowan Collins wrote: Thinking about it, the only part that has some value being in core is the HTML rewriting. Perhaps what is actually needed is a lower-level function that PHP libraries can use to hook into this with whatever parameters they want, e.g.