Re: [PHP-DEV] New escaped output operator

> If you're answer for the other contexts is to use a template engine, > why is the answer for this not to use a template engine? > You want to add this because people don't use template engine, > so what makes you think they will use this when there is a valid solution already available? Because

Re: [PHP-DEV] [RFC] Iterable

On Thu, Jun 30, 2016 at 10:01 PM, Jeremy Mikola wrote: > On Sat, Jun 18, 2016 at 11:34 AM, Aaron Piotrowski > wrote: > > > > > I plan on bringing the iterable RFC (https://wiki.php.net/rfc/iterable) > > to a vote in about a week, does anyone have any

Re: [PHP-DEV] New escaped output operator

> What for? is easy to verify is not easy to verify Regards Rasmus Schultz wrote on 30.06.2016 22:27: > I wish you'd think about the bigger issue of autoloading functions, > which would solve this and many similar problems much more generally. > > I mean, this: > > > > versus this: > >

Re: [PHP-DEV] [RFC][Vote] ReflectionType Improvements

On Thu, Jun 30, 2016 at 6:06 PM, Levi Morrison wrote: > The RFC for improving ReflectionType[1] is now in voting phase. The voting > window is June 30th through July 8th. I have not finished the patch but > I'll have it done before the end of voting. > > [1]:

Re: [PHP-DEV] [RFC][Vote] Throw Error in Extensions

Hi Chris, > On Jun 30, 2016, at 6:15 AM, Christopher Jones > wrote: > > Hi Aaron, > > I was someone who spent time on the RFC template to try and get better > quality and to capture more information about each RFC. I think your > RFC needs a lot more content

Re: [PHP-DEV] New escaped output operator

On Thu, Jun 30, 2016 at 1:35 PM, Михаил Востриков < michael.vostri...@gmail.com> wrote: > > > - Other people will ask about operator for another context > And you can say: We already added an operator for the main web context, > because it is the most frequently used context. If you have a lot of

Re: [PHP-DEV] New escaped output operator

I wish you'd think about the bigger issue of autoloading functions, which would solve this and many similar problems much more generally. I mean, this: versus this: What for? I don't see the point in inventing new syntax, and introducing a new concept, for what is effectively just a

Re: [PHP-DEV] [RFC][Vote] Throw Error in Extensions

On 30 June 2016 at 01:32, Pierre Joye wrote: >> It's not a language change, so doesn't seem to meet the criteria for >> needing a 2/3 pass rate. > > It is changing the core like ext/standard and other core functions. That's true, but doesn't appear to be the required test.

Re: [PHP-DEV] [RFC] Iterable

On Sat, Jun 18, 2016 at 11:34 AM, Aaron Piotrowski wrote: > > I plan on bringing the iterable RFC (https://wiki.php.net/rfc/iterable) > to a vote in about a week, does anyone have any further feedback on this > proposal? > Was there any discussion about a special allowance

Re: [PHP-DEV] New escaped output operator

I would prefer to have ENT_HTML5 as the default flag included, since normally all new html code is html5. Maybe split voting between I've tried to gather all arguments for and against. > > To be clear. I suggest new operator like '' which is > equivalent of . > It is only for HTML context. Flag

Re: [PHP-DEV] New escaped output operator

I've tried to gather all arguments for and against. To be clear. I suggest new operator like '' which is equivalent of . It is only for HTML context. Flag combination is taken from most popular frameworks - Symfony, Zend, Yii, and Twig. Of course, exact form of operator and default flags are the

[PHP-DEV] Request: Prevention of FPD in Fatal/Parse/Other Errors

Hi, Currently the only real "solution" to Full Path Disclosure vulnerabilities in software developed in PHP is to keep display_errors disabled. Even if a developer wishes to prevent disclosures at the application level instead, it is not currently possible with the current implementation of

[PHP-DEV] [RFC][Vote] ReflectionType Improvements

The RFC for improving ReflectionType[1] is now in voting phase. The voting window is June 30th through July 8th. I have not finished the patch but I'll have it done before the end of voting. [1]: https://wiki.php.net/rfc/ReflectionTypeImprovements

[PHP-DEV] BAD Benchmark Results for PHP Master 2016-06-30

Results for project PHP master, build date 2016-06-30 06:30:36+03:00 commit: e247e93 previous commit:0a4f89b revision date: 2016-06-29 20:51:10+01:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

[PHP-DEV] PDO_pgsql and "?" json operator (was [PHP-DEV] About PHP 7.1.0 Feature Freeze)

Hi Davey, I'm patching in internals again, as I should probably have done in the first place ;) On 30/06/2016 13:04, Davey Shafik wrote: >> On Thu, Jun 30, 2016 at 3:56 AM, Matteo Beccati > > wrote: >> >> Hi Davey, Joe, >> >> I'm sending this

Re: [PHP-DEV] [RFC][Vote] Throw Error in Extensions

On 28/06/2016 1:17 AM, Aaron Piotrowski wrote: Hello, Voting has opened on the RFC to change most conditions in extensions that raise E_ERROR or E_RECOVERABLE_ERROR to throw an instance of Error instead. RFC: https://wiki.php.net/rfc/throw_error_in_extensions

[PHP-DEV] Re: [RFC] RNG fixes

Updated RFC * Removed proposal to replace (mt_)rand with an alternative algorithm as many have expressed concerns with this. * Clarified that the output of mt_rand _appears_ to be high quality as-is * Added that the old mt_rand functionality will be available at runtime via `mt_rand_mode()` I'll