On 21.07.2016 06:37, Sara Golemon wrote:
> On Wed, Jul 20, 2016 at 8:50 PM, Larry Garfield
> wrote:
[...]
> return $this->loadConfig()
> |> $arg->useConfig($$)
> |> $this->loadUser($$)
> |> array_merge($$, $this->userDefaults);
>
> But the PSR7 example is already contrived as it i
On Wed, Jul 20, 2016 at 8:50 PM, Larry Garfield wrote:
> I am still generally in favor of this proposal. Especially when dealing
> with nested array functions this operator would be a big boon to
> readability.
>
That's honestly my 90% use-case as well. array_merge and array_filter
in particular
> On Thu, Jul 21, 2016 at 9:05 AM, Thomas Bley wrote:
> to me this code is perfectly readable and static code analysis is only
> complaining about missing semicolons at the end of the lines and short
> variable names:
>
> $x = loadConfig();
> $x = buildDic($x);
> $x = getApp($x)
> $x = getRouter
On 07/20/2016 07:42 PM, Sara Golemon wrote:
With the branching of 7.1, and after some reflection on the previous
feedback, I'd like to reopen discussion of the Pipe Operator RFC
https://wiki.php.net/rfc/pipe-operator which I had previously put on
hold. I've changed much of the argument wording o
Hi Derick,
On Tue, Jul 12, 2016 at 7:25 PM, Derick Rethans wrote:
> The voted-upon-RFC still has
>
>> session.use_strict_mode (0 to 1) - Changed as insurance of broken PRNG
>> implementation.
>
> Although you said:
>
> It was moved to other RFC.
>
> https://wiki.php.net/rfc/s
Hi Thomas,
On Thu, Jul 21, 2016 at 9:05 AM, Thomas Bley wrote:
> to me this code is perfectly readable and static code analysis is only
> complaining about missing semicolons at the end of the lines and short
> variable names:
>
> $x = loadConfig();
> $x = buildDic($x);
> $x = getApp($x)
> $x =
to me this code is perfectly readable and static code analysis is only
complaining about missing semicolons at the end of the lines and short variable
names:
$x = loadConfig();
$x = buildDic($x);
$x = getApp($x)
$x = getRouter($x)
$x = getDispatcher($x, $request)
$x = dispatchBusinessLogic($x, $
With the branching of 7.1, and after some reflection on the previous
feedback, I'd like to reopen discussion of the Pipe Operator RFC
https://wiki.php.net/rfc/pipe-operator which I had previously put on
hold. I've changed much of the argument wording of the proposal, but
not the substantive featur
Hey folks,
as mentioned in the last release email, the PHP-7.1 branch has now been
created.
I will be creating the PHP 7.1.0beta1 release off it in the next few
minutes.
However, this effectively means that master is open for PHP 7.2 (or 8.0 :P)
and any further commits specifically for 7.1 must
This is a really good point, Marco.
Of course, this would be much cleaner with a set of functions, since $this
(whatever it is) is not truly a dependency for any of these functions -
they're likely sharing no context or state; they've likely been placed in
the class solely to make them available t
> escapeHtml($value); ?>
> I don't see what is hard in using that syntax, plus it's not a global
registry.
> if people aren't using templating and haven't written any of their own
wrappers to sanitize the output
They HAVE own wrappers. The problem is that unsafe variant works good, but
unsafe vari
Greetings,
I made a small fix/adjustment to lastInsertId on pdo_pgsql on branch 7.0.9.
It builded ok, there's a PR for it (https://github.com/php/php-src/pull/2014)
and I just wondered about if I should apply it on 7.1.0, 5.6.whatever, and
5.5.whatevertoo. The point about applying it to 7.1 seems
On Wed, Jul 20, 2016 at 12:17 PM, Michael Vostrikov <
michael.vostri...@gmail.com> wrote:
> > Personally I don't know any developer who is using raw php in project
> without template engine
>
> Zend, Yii, various CMS like Wordperss, internal business-applications - in
> many cases such projects do
The syntax is weird as heck.
That said, frameworks without templating engine already have escaping
helpers, for example:
escapeHtml($value); ?>
escapeHtmlAttr($value); ?>
escapeJs($value); ?>
escapeCss($value); ?>
I don't see what is hard in using that syntax, plus it's not a global
registry.
Ma
> Personally I don't know any developer who is using raw php in project
without template engine
Zend, Yii, various CMS like Wordperss, internal business-applications - in
many cases such projects don't have a template engine.
I usually work with Yii and internal applications on custom engines. Thi
20 lip 2016 19:03 "Michael Vostrikov"
napisał(a):
>
> > You are creating weird most of time unneded quite complex syntax. Just
> use escaping functions or any other escaper or just simply template engine
> as most of people does!
>
> I explained the reasons for implementing this operator in previo
> You are creating weird most of time unneded quite complex syntax. Just
use escaping functions or any other escaper or just simply template engine
as most of people does!
I explained the reasons for implementing this operator in previous
discussion and in the "Problem description" section of the
hi,
we had a wrong merge in the php-src, merging master into 5.6. I've just
force pushed the last good version before the bogus merge. You can find the
bogus state at https://github.com/tyrael/php-src/tree/broken-5.6-20140206
if you happen to have some commits which you still want to have in PHP-5
Good morning!
We received a support ticket from a customer who’s using our PHP 7 binaries
with Atomic Secured Linux. They are advising that our lsphp binary for PHP7 is
insecure, while the other lsphp binaries for PHP 5 are ‘not insecure’. The
errors the customer is getting are below
Jul 18 22
You are creating weird most of time unneded quite complex syntax. Just use
escaping functions or any other escaper or just simply template engine as
most of people does!
19 lip 2016 21:52 "Michael Vostrikov"
napisał(a):
> > This can be used for all context-dependent text transformations
> On the
On Wed, 20 Jul 2016, Davey Shafik wrote:
> Hey All (particularly Julien & Ferenc),
>
> While working on an issue caused by re2c+ext/date on OS X that was holding
> up 7.1.0beta1 and causing the latest 7.0 bulld to need to be re-tagged:
>
> I accidentally messed up due to lack of sleep and merged
Hey All (particularly Julien & Ferenc),
While working on an issue caused by re2c+ext/date on OS X that was holding
up 7.1.0beta1 and causing the latest 7.0 bulld to need to be re-tagged:
I accidentally messed up due to lack of sleep and merged master into
PHP-5.6. Because I cannot force push to t
Results for project PHP master, build date 2016-07-20 06:29:15+03:00
commit: a179b14
previous commit:88d86ae
revision date: 2016-07-19 20:35:04+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
Hi Bishop,
On Wed, Jul 20, 2016 at 9:47 AM, Bishop Bettini wrote:
>> To decide next move, I would like to start hearing the reason why from
>> those who are against this RFC.
>
>
> I abstained from voting. While I would be a "Yes" in principle, two specific
> statements in the RFC made me wary of
On Tue, 19 Jul 2016, Davey Shafik wrote:
> while trying to run tests on OS X I ran into a performance issue that
> effectively boils down to this commit:
> https://github.com/php/php-src/commit/7759d6b0db0437195442ea2d43e1a49001ef23a7
You're going to have to be more specific than "performance i
25 matches
Mail list logo