[PHP-DEV] Re: Object getter method optimization

> > >> I was playing with this idea sometime ago, it gives good performance > boost for code like `for ($i = 0; $i < 10; $i++) $a->getFoo();` but in > the end of the day it's a very limited optimization. > If you abstract away from getters and say you want to optimize more and > more small

Re: [PHP-DEV] Re: RFC Proposal: Maybe monad and execution time polymorphic methods

On Mon, Mar 21, 2016 at 5:03 PM, Stephen Coakley wrote: > On 03/21/2016 03:04 PM, Facundo Martinez Correa wrote: >> >> So I want to "return a NULL". I want to express uncertainty, a >> nonexistence. But I want to express that I will return something. And I >> want to

Re: [PHP-DEV] RFC Proposal: Maybe monad and execution time polymorphic methods

Le lundi 21 mars 2016, 17:04:30 Facundo Martinez Correa a écrit : > But then I realized the problem. There > are many times where we need uncertainty. Code is a reflection of reality, > and as such, it must reflect uncertainty. NULL is a good enough way to > express nonexistence, albeit a bad one.

Re: [PHP-DEV] PCRE JIT stack size limit

On 21.03.2016, at 23:44, Anatol Belski wrote: > > What I'm suggesting to do is using a bit finer comb checking with the real > life situations. Fe what would be the win for the user, either having to > enable JIT by hand, or to disable it in a rare case. Currently, as for

[PHP-DEV] Re: RFC Proposal: Maybe monad and execution time polymorphic methods

On 03/21/2016 03:04 PM, Facundo Martinez Correa wrote: So I want to "return a NULL". I want to express uncertainty, a nonexistence. But I want to express that I will return something. And I want to have this NULL checking at interpretation time. I want everything, and none of the drawbacks. As

RE: [PHP-DEV] PCRE JIT stack size limit

Hi David, > -Original Message- > From: David Zuelke [mailto:d...@heroku.com] > Sent: Monday, March 21, 2016 10:52 PM > To: Anatol Belski > Cc: Christoph Becker ; Pierre Joye > ; PHP internals >

Re: [PHP-DEV] PCRE JIT stack size limit

On 21.03.2016, at 19:41, Anatol Belski wrote: > I've just pushed a fix for this issue, could you please check? A global > stack space > Is used in a thread safe manner. I was first setting max to 256K, then > decreased it > To 64K for now. My tests on Linux and Windows show

RE: [PHP-DEV] PCRE JIT stack size limit

Hi, > -Original Message- > From: Nikita Popov [mailto:nikita@gmail.com] > Sent: Monday, March 21, 2016 7:54 PM > To: Anatol Belski > Cc: David Zuelke ; Christoph Becker ; > Pierre Joye ; PHP internals

Re: [PHP-DEV] RFC Proposal: Maybe monad and execution time polymorphic methods

Hi Levi, Thanks for replying. I don't think that automagically taking the T out of the Maybe would be a good idea, mainly because sometimes you don't need the T, you just want to know the result of it. What I would want in that PHP automagically executes the method myMethod(Maybe $object) if

Re: [PHP-DEV] RFC Proposal: Maybe monad and execution time polymorphic methods

> My experience in Haskell reminded me of this. To have a structure than > represents uncertainty, is the best way to take away the responsibility > from NULL. To express it in no other way. But my experience in Java has > taught me that Optional of something is not a good way to tackle the >

Re: [PHP-DEV] PCRE JIT stack size limit

On 21.03.2016, at 19:54, Nikita Popov wrote: > > On Mon, Mar 21, 2016 at 7:41 PM, Anatol Belski wrote: >> The issue I have with more increasing the stack is that - while as we see >> till today >> the default stack size of 32K is enough in the common

[PHP-DEV] RFC Proposal: Maybe monad and execution time polymorphic methods

Hello, I am reaching you in order to obtain feedback on this RFC proposal. I have been playing with PHP 7 for a project in the company that I am currently working for. One of the many drawbacks that I saw in PHP was the there were no types. With type hinting I had confindence again in PHP. With

[PHP-DEV] Re: RFC about automatic template escaping

Hi Daniel, When I write scripts that need to behave the same independently of the value of mbstring.func_overload then I have to remember to be careful with the functions it affects. It's a drag. I resent having to write things like mb_strlen($str, '8bit') to get a byte-count knowing that the

Re: [PHP-DEV] PCRE JIT stack size limit

On Mon, Mar 21, 2016 at 7:41 PM, Anatol Belski wrote: > Hi, > > > -Original Message- > > From: David Zuelke [mailto:d...@heroku.com] > > Sent: Monday, March 21, 2016 12:30 AM > > To: Anatol Belski > > Cc: Christoph Becker

RE: [PHP-DEV] PCRE JIT stack size limit

Hi, > -Original Message- > From: David Zuelke [mailto:d...@heroku.com] > Sent: Monday, March 21, 2016 12:30 AM > To: Anatol Belski > Cc: Christoph Becker ; Pierre Joye > ; PHP internals > Subject:

Re: [PHP-DEV] OpenSSL ext status including port to OpenSSL 1.1

Hi David On Sun, Mar 20, 2016 at 9:08 PM, David Zuelke wrote: > On 20.03.2016, at 20:50, Jakub Zelenka wrote: > > > > Hi, > > > > I just wanted to send a quick update about my recent work on openssl ext > in > > case someone else wanted to start something

Re: [PHP-DEV] [RFC Discussion] Typed Properties

On Mon, Mar 21, 2016 at 4:37 PM, Rowan Collins wrote: > Andrea Faulds wrote on 17/03/2016 22:32: > >> Hi Johannes, >> >> Johannes Schlüter wrote: >> >>> On Wed, 2016-03-16 at 19:15 +0100, Bob Weinand wrote: >>> Eih, only to typed properties. Everything else

Re: [PHP-DEV] [RFC Discussion] Typed Properties

Andrea Faulds wrote on 17/03/2016 22:32: Hi Johannes, Johannes Schlüter wrote: On Wed, 2016-03-16 at 19:15 +0100, Bob Weinand wrote: Eih, only to typed properties. Everything else would be insane ;-) Sorry for being imprecise. Ok, quite a lot better, but still weird difference to the

[PHP-DEV] Registration wiki.php.net

I would like to register Grateful -- Augusto S Batista

Re: [PHP-DEV] RFC about automatic template escaping

Hi, basically I agree to you while I see the issue, but I don't think this is the solution (it might have been a solution if introduced 20 years ago, making it "secure by default" and let users opt-out where needed, but now might lead to a BC hell now) But a comment here: On Mon, 2016-03-21 at

Re: [PHP-DEV] RFC about automatic template escaping

Honestly, as it stands this is a pretty terrible idea. 1. It has a huge potential for introducing BC breaks. - I have some code somewhere which uses output buffering and echo to write cached copies of html pages to disk. This would break that. - Writing out html like structures when running as

Re: [PHP-DEV] RFC about automatic template escaping

Daniel Beardsley wrote on 21/03/2016 06:35: You are right. Though not all those problems are serious: * URI escaping: Does anyone really use or echo when generating a uri? * Javascript: Good point, though I would say it's fairly rare to create javascript code using a php template with

[PHP-DEV] GOOD Benchmark Results for PHP Master 2016-03-21

Results for project PHP master, build date 2016-03-21 06:28:02+02:00 commit: dab8e58 previous commit:48e3459 revision date: 2016-03-20 18:18:14+01: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] RFC about automatic template escaping

> I think having the behaviour of language features depend in an incompatible > way on a global runtime setting is a bad idea because it creates nonlocal > effects and means code cannot be realiably composed. This is probably the best argument against this RFC. Though how often that issue would

Re: [PHP-DEV] RFC about automatic template escaping

I think having the behaviour of language features depend in an incompatible way on a global runtime setting is a bad idea because it creates nonlocal effects and means code cannot be realiably composed. Effectively, every function and method will have an implicit assumption about whether or not it

Re: [PHP-DEV] RFC about automatic template escaping

> The similarity is that magic quotes assumed that the input data was going to > be embedded within an SQL query without escaping, and therefore needed > escaping. Of course that's an invalid assumption, the input data could be > re-rendered, processed in some arbitrary way, written to a file,

Re: [PHP-DEV] RFC about automatic template escaping

On Mon, Mar 21, 2016 at 4:53 PM, Daniel Beardsley wrote: > > This approach has the smell of magic quotes which we got rid of for > > very good reason. XHP is much more explicit in separating markup from > > data and relies far less (not at all when you do it right) on escape

Re: [PHP-DEV] Huge Pages

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 20/03/2016 05:29, Rasmus a écrit : > We have a bit of a problem with how Linux handles huge pages when > you run out of them. Yes, especially on old kernel (2.6.32 on RHEL-6) For the build in my repository : - - RHEL-6 : build with

Re: [PHP-DEV] RFC about automatic template escaping

> Wouldn't this __auto_escape setting effectively break libraries that depend > on it being on or off? The settings was meant to be turned on *only* during template rendering. So, yes, if outside code is run during your template rendering that also uses templating, but is unaware of auto

Re: [PHP-DEV] RFC about automatic template escaping

> Issue is "Escaping is done on a specific context". > > I understand your proposal is focused on HTML escaping. However, > setting names like > __auto_escape_exempt_class > is not good choice. It has to be > __auto_html_escape_exempt_class > at least because it is for HTML escaping. Yes, the ini

Re: [PHP-DEV] RFC about automatic template escaping

> I agree XHP really is the right solution for this problem. It enables HTML > to be created structurally and composably with a concise inline syntax, just > like JSX/React does for JavaScript, and just like LINQ does for SQL in C#. > It's much better than passing around snippets of HTML as

Re: [PHP-DEV] RFC about automatic template escaping

On Mar 21, 2016 12:53 PM, "Daniel Beardsley" wrote: > > > > T_ECHO (echo, > > ZEND_AST_ECHO_ESCAPE node in the syntax tree. > > > > > Interesting approach, I assume an explicit `echo $foo;` takes the > > normal ZEND_ECHO route then? > > No, looking at the code and tests: echo,

Re: [PHP-DEV] RFC about automatic template escaping

Wouldn't this __auto_escape setting effectively break libraries that depend on it being on or off? People often write code to generate HTML like this: ob_start(); ?> some HTML more HTML wrote: > Hi Daniel, > > On Mon, Mar 21, 2016 at 7:11 AM, Daniel Beardsley >