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

2016-05-08 Thread Stanislav Malyshev
Hi! > "|>" is just a building block for simpler coding. It could be used badly, but > it helps a lot. Procedural code could be much simpler and readable with "|>". I don't see how it helps anything. It just replaces clear variable names with cryptic sequences of characters with no intuitive

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

2016-05-08 Thread Yasuo Ohgaki
Hi, I agree they are bad APIs. Framework/library developer should provide better API On Mon, May 9, 2016 at 1:08 AM, Fleshgrinder wrote: > $request = getGlobals() > |> parseRequest($$) > |> buildPsr7Request($$); should be require('some.lib'); $request =

Re: [PHP-DEV] How to get trace of all database queries executed by php

2016-05-08 Thread Zeev Suraski
> On 7 במאי 2016, at 2:35, Raja Kulasekaran wrote: > > Hi, > > Sorry If I am asking this question in irrelevent forum. > Please suggest me the point of direction if not. > > I have encrypted php Application codebase which I may or may not have > access. > > So, I would

[PHP-DEV] [RESULT] Square bracket syntax for array destructuring assignment

2016-05-08 Thread Andrea Faulds
Hi everyone, Voting on Bob and I's RFC for a shorter syntax for list() ran from 2016-04-27 to 2016-05-08, and has now closed. By 41 votes in favour to none against, the RFC has been approved for PHP 7.1. We will now work towards merging into master. Votes can be seen on the RFC page:

Re: [PHP-DEV] How to get trace of all database queries executed by php

2016-05-08 Thread Johannes Schlüter
Hi, On Fri, 2016-05-06 at 19:34 -0400, Raja Kulasekaran wrote: > Is there any php extension available which help me out to give the > statistics of > all the queries execution details ? if you are on a development machine (thus no unrelated traffic) something like a query log (in MySQL

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

2016-05-08 Thread Fleshgrinder
On 5/3/2016 11:23 PM, Ryan Pallas wrote: > Waiting for what example? There's been plenty of examples showing how > existing options, rewritten with |> are easier. If you disagree, that's an > opinion, other's agree. If people think its better, why not add it for > them? Like every other feature

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

2016-05-08 Thread Fleshgrinder
On 5/6/2016 8:02 AM, Dmitry Stogov wrote: > On 05/06/2016 05:06 AM, Jesse Schalken wrote: >> If you're going to say "do what you want" with regards to annotations, >> then >> just let them be a text string. Parsing the annotation as PHP but not >> evaluating it as PHP seems a very strange and

Re: [PHP-DEV] Allow empty property names

2016-05-08 Thread Jakub Zelenka
Hi, I have been thinking about it and I would be ok with removing _empty_ in 7.1. That inconsistency is quite annoying and I never liked it. If we can rid of it, that would be great! I realise the BC concern but I see that more as a limitation and inconsistency between array and object decoding.

Re: [PHP-DEV] Re: [RFC] Pre-vote notice for Nullable Types

2016-05-08 Thread Nikita Popov
On Sun, May 8, 2016 at 3:54 PM, Tom Worster wrote: > On 5/7/16, 1:19 PM, "Nikita Popov" wrote: > > >This RFC has one primary vote and one secondary vote. The primary vote > >determines whether we want to add nullable types to our type system. The >

Re: [PHP-DEV] Re: [RFC] Pre-vote notice for Nullable Types

2016-05-08 Thread Tom Worster
On 5/7/16, 1:19 PM, "Nikita Popov" wrote: >This RFC has one primary vote and one secondary vote. The primary vote >determines whether we want to add nullable types to our type system. The >secondary vote decides how precisely this will happen, in this instance >deciding

Re: [PHP-DEV] [RFC] Pre-vote notice for Nullable Types

2016-05-08 Thread Björn Larsson
Den 2016-05-06 kl. 21:41, skrev Levi Morrison: The [RFC for Nullable Types][1] is going to go into the voting phase soon. There have been a few changes to the RFC in the meantime: - More example for documentation's sake - The vote is now split into two parts: one for nullable parameter