Re: [PHP-DEV] [RFC] [Vote] Callable types (now: Callable prototypes)

[Nikita Nefedov]

On Mon, 23 May 2016 22:52:18 +0300, Levi Morrison  wrote:

On Mon, May 23, 2016 at 1:19 PM, Nikita Nefedov   
wrote:



On 23 May 2016, at 19:31, Levi Morrison  wrote:

A quick question before I vote: do callable prototypes allow for
default parameters in the signature? There are examples for having a
function passed that has a default parameters but I am not seeing it
anywhere in the callable prototype definition so I thought I'd ask.


Hey Levi,

Although it could be done as a later RFC, my stance on it is that  
default values don't belong to the prototype of the function.


Why I think that callable typehint doesn't need default values for  
params is: you either need this parameter to exist and even if there  
are cases where you'd like to pass some kind of 'default' value  
implicitly, you as a caller shouldn't impose on the callee  
responsibility to have this same value in his definition and instead  
just pass your argument explicitly... or if you don't need this  
parameter (as in you don't plan to pass anything explicitly) then you  
should just ask for a function without this parameter as there is  
clearly no need for it at all.


Moreover I would argue interfaces have it wrong here too: the fact that  
default values are part of an interface yet their invariance is not  
enforced, yields an interesting sort of possible LSP violation. F.e. if  
we have an interface Logger (a completely unreal example but it shows  
what can go wrong) with function 'log($message, $level = LOG_DEBUG);'  
and a funny implementation that decided to change default value of  
$level to LOG_ALERT, then all callers of Logger#log who relied on the  
fact that level if not specified, will be LOG_DEBUG, who also happen to  
get the funny implementation of Logger will produce unneeded noise in  
the logs with their alert level messages which were intended to be  
debug messages :(


Please document this restriction in the RFC. I guess I'm the only one
who expected it to be there since it didn't come up before, but it
just seems missing. You don't need to take it out of voting for this
clarification, imo.


Morning,

sure thing, added it in the RFC

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

[Jesse Schalken]

I'm curious, what is it about $this that makes it special in the first
place? Can't it be a normal local variable that happens to already be
assigned at the start of a method?

On Tue, May 24, 2016 at 6:24 AM, Dmitry Stogov  wrote:

> Hi internals,
>
>
> Please review the RFC.
>
> It proposes to fix all known inconsistencies related to handling of
> special $this variable.
>
>
> https://wiki.php.net/rfc/this_var
>
>
> Thanks. Dmitry.
>

Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

[Xinchen Hui]

Hey:



On Tue, May 24, 2016 at 4:24 AM, Dmitry Stogov  wrote:

> Hi internals,
>
>
> Please review the RFC.
>
> It proposes to fix all known inconsistencies related to handling of
> special $this variable.
>
in section static this,   actually, the codes doesn't work in 7.0 neither.

it will result in fatal error:   PHP Fatal error:  Cannot re-assign $this

thanks

>
> https://wiki.php.net/rfc/this_var
>
>
> Thanks. Dmitry.
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] [RFC] [Vote] Callable types (now: Callable prototypes)

[Dan Ackroyd]

Hi Nikita,

On 23 May 2016 at 15:27, Nikita Nefedov  wrote:
> With this message I'd like to go to vote
> with the Callable prototypes RFC targeted at 7.1:
> https://wiki.php.net/rfc/callable-types

To explain my vote - I think we definitely need to be able to specify
the signatures of callables in PHP, and I would very probably support
either a 'typedef' RFC, or an expansion of current functional type
(i.e. invokables) to be easier to use with functions, but I just
couldn't possibly vote for an RFC that means people would sometimes
write code similar to this:

function foo(int $a, int $b,
callable(callable(callable(callable(int, int):int $zebranky, int):int
$pik, int):int $fot, int):int $zot): int {
return $zot($a, $b);
}

to use the feature of the RFC.

I realise that is an extreme case, but I think that splitting where a
type is defined (with a name) and the place where it is used to be
separate places, is one of the things that the design of PHP got
right. It makes it easier to read code, even if it makes the language
feel less 'powerful' than other languages.

cheers
Dan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: "finally" handling refactoring (Bug #72213)

[Nikita Popov]

On Mon, May 23, 2016 at 11:36 PM, Dmitry Stogov  wrote:

> Hi,
>
> On 05/23/2016 07:24 PM, Nikita Popov wrote:
>
> On Mon, May 23, 2016 at 1:25 PM, Dmitry Stogov  wrote:
>
>> Thanks for review.
>>
>> Both problems should be fixed now
>> 
>> https://gist.github.com/dstogov/0a809891c6a3ac3fac4bd0d9711dd330
>>
>> Do you see any other problems or a better way to fix this?
>>
> Your fix for DISCARD_EXCEPTION does not look right to me. It will discard
> all exceptions too early. For example:
>
> function test() {
> try {
> throw new Exception(1);
> } finally {
> try {
> try {
> } finally {
> return 42;
> }
> } finally {
> throw new Exception(2);
> }
> }
> }
>
> test();
>
> This will now not chain exception 1 and 2, because exception 1 is
> discarded at the return statement.
>
>
> I thought about this, and I think that the current behavior is right.
> If we remove "throw new Exception(2);" the first exception is going to be
> discarded at "return 42;".
> I think we should do the same independently from the context.
>
> Why do you think Exception(1) should be kept?
>

Because Exception(3) may be discarded by another catch in the finally, in
which case we should throw Exception(1). Consider this case:

function test() {
try {
throw new Exception(1);
} finally {
try {
try {
try {
} finally {
return 42;
}
} finally {
throw new Exception(3);
}
} catch (Exception $e) {}
}
}

test();

This should throw Exception(1), as Exception(3) is thrown and caught inside
the finally block. I thought your current patch would not throw anything in
this case, but I'm actually getting an assertion failure (and a conditional
jump on uninit value in valgrind):

php: /home/nikic/php-src/Zend/zend_gc.c:226: gc_possible_root: Assertion
`(ref)->gc.u.v.type == 7 || (ref)->gc.u.v.type == 8' failed.


> I think this should be handled the same way we do the fast_call dispatch
> on return, i.e. when we pop the FAST_CALL from the loop var stack we should
> replace it with a DISCARD_EXCEPTION and then pop it after the finally. This
> should generate all the necessary DISCARD_EXCEPTION opcodes, and in the
> right order.
>
>
> May be I'll commit the existing fix, and you'll try to implement this idea
> on top?
>
> Thanks. Dmitry.
>
>
> Nikita
>
>
>

Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

[James Gilliland]

In the section "Disable ability to re-assign $this indirectly through $$"
it looks like there is a typo. It only makes sense if you mean $$a instead
of $aa.

[PHP-DEV] Re: "finally" handling refactoring (Bug #72213)

[Dmitry Stogov]

Hi,


On 05/23/2016 07:24 PM, Nikita Popov wrote:
On Mon, May 23, 2016 at 1:25 PM, Dmitry Stogov > wrote:


Thanks for review.

Both problems should be fixed now
https://gist.github.com/dstogov/0a809891c6a3ac3fac4bd0d9711dd330

Do you see any other problems or a better way to fix this?

Your fix for DISCARD_EXCEPTION does not look right to me. It will 
discard all exceptions too early. For example:


function test() {
try {
throw new Exception(1);
} finally {
try {
try {
} finally {
return 42;
}
} finally {
throw new Exception(2);
}
}
}

test();

This will now not chain exception 1 and 2, because exception 1 is 
discarded at the return statement.


I thought about this, and I think that the current behavior is right.
If we remove "throw new Exception(2);" the first exception is going to 
be discarded at "return 42;".

I think we should do the same independently from the context.

Why do you think Exception(1) should be kept?



I think this should be handled the same way we do the fast_call 
dispatch on return, i.e. when we pop the FAST_CALL from the loop var 
stack we should replace it with a DISCARD_EXCEPTION and then pop it 
after the finally. This should generate all the necessary 
DISCARD_EXCEPTION opcodes, and in the right order.


May be I'll commit the existing fix, and you'll try to implement this 
idea on top?


Thanks. Dmitry.



Nikita

Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

[Dmitry Stogov]

good point. I'll update RFC and patch to support extract() and 
get_defined_vars().


From: Nikita Popov 
Sent: Monday, May 23, 2016 11:46:35 PM
To: Dmitry Stogov
Cc: internals; Nikita Popov; Bob Weinand; Xinchen Hui
Subject: Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

On Mon, May 23, 2016 at 10:24 PM, Dmitry Stogov 
> wrote:

Hi internals,


Please review the RFC.

It proposes to fix all known inconsistencies related to handling of special 
$this variable.


https://wiki.php.net/rfc/this_var


Thanks. Dmitry.

How does this interact with things like extract() or get_defined_vars()?

The"static function __call()" case looks like a bug... Shouldn't this just be a 
compiler error in the first place?

Nikita

Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

[Nikita Popov]

On Mon, May 23, 2016 at 10:24 PM, Dmitry Stogov  wrote:

> Hi internals,
>
>
> Please review the RFC.
>
> It proposes to fix all known inconsistencies related to handling of
> special $this variable.
>
>
> https://wiki.php.net/rfc/this_var
>
>
> Thanks. Dmitry.
>
How does this interact with things like extract() or get_defined_vars()?

The"static function __call()" case looks like a bug... Shouldn't this just
be a compiler error in the first place?

Nikita

[PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

[Dmitry Stogov]

Hi internals,


Please review the RFC.

It proposes to fix all known inconsistencies related to handling of special 
$this variable.


https://wiki.php.net/rfc/this_var


Thanks. Dmitry.

Re: [PHP-DEV] [RFC] [Vote] Callable types (now: Callable prototypes)

[Markus Fischer]

Hello Nikita,

On 23.05.16 21:27, Nikita Nefedov wrote:
> When you pass an `int` to a `string` type parameter in weak mode
> it's being coerced to the needed type (not just directly passed).
> 
> This is quite complex, because you'd need to copy zend_function
> and all its members (without changing the original zend_function).
> 
> I would love to support it but all in all it comes down to
> implementation here for me, so I'd rather do it in a separate
> RFC.


I like the RFC, however I do not like this behavior.
This would behave differently then how current weak/strict mode works.

I was never a fan of the weak mode to begin with, but now introducing
something which deals in the area of argument passing and not behaving
to what a 2/3 majority agreed is IMHO a no-go. The current RFC does not
even mention that.

Maybe it's not feasible anyway, but in any case I'm missing
input/discussion in this area.

- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Vote] Callable types (now: Callable prototypes)

[Levi Morrison]

On Mon, May 23, 2016 at 1:19 PM, Nikita Nefedov  wrote:
>
>> On 23 May 2016, at 19:31, Levi Morrison  wrote:
>>
>>> On Mon, May 23, 2016 at 8:27 AM, Nikita Nefedov  wrote:
>>> Evening internals,
>>>
>>> With this message I'd like to go to vote
>>> with the Callable prototypes RFC targeted at 7.1:
>>> https://wiki.php.net/rfc/callable-types
>>>
>>> We've renamed it (previously was "Callable types") as RFC names often
>>> dictate how users will call the feature and I want it to be more
>>> accurate/descriptive.
>>>
>>> Also the reflection part was added although I'm short on time currently,
>>> so implementation for that will be ready later. (speaking of implementation,
>>> it also currently doesn't use cache_slots - also something I'll add when
>>> I have a little bit of time)
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>> A quick question before I vote: do callable prototypes allow for
>> default parameters in the signature? There are examples for having a
>> function passed that has a default parameters but I am not seeing it
>> anywhere in the callable prototype definition so I thought I'd ask.
>
> Hey Levi,
>
> Although it could be done as a later RFC, my stance on it is that default 
> values don't belong to the prototype of the function.
>
> Why I think that callable typehint doesn't need default values for params is: 
> you either need this parameter to exist and even if there are cases where 
> you'd like to pass some kind of 'default' value implicitly, you as a caller 
> shouldn't impose on the callee responsibility to have this same value in his 
> definition and instead just pass your argument explicitly... or if you don't 
> need this parameter (as in you don't plan to pass anything explicitly) then 
> you should just ask for a function without this parameter as there is clearly 
> no need for it at all.
>
> Moreover I would argue interfaces have it wrong here too: the fact that 
> default values are part of an interface yet their invariance is not enforced, 
> yields an interesting sort of possible LSP violation. F.e. if we have an 
> interface Logger (a completely unreal example but it shows what can go wrong) 
> with function 'log($message, $level = LOG_DEBUG);' and a funny implementation 
> that decided to change default value of $level to LOG_ALERT, then all callers 
> of Logger#log who relied on the fact that level if not specified, will be 
> LOG_DEBUG, who also happen to get the funny implementation of Logger will 
> produce unneeded noise in the logs with their alert level messages which were 
> intended to be debug messages :(

Please document this restriction in the RFC. I guess I'm the only one
who expected it to be there since it didn't come up before, but it
just seems missing. You don't need to take it out of voting for this
clarification, imo.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Vote] Callable types (now: Callable prototypes)

[Nikita Nefedov]

Hi Bob,

When you pass an `int` to a `string` type parameter in weak mode
it's being coerced to the needed type (not just directly passed).

This is quite complex, because you'd need to copy zend_function
and all its members (without changing the original zend_function).

I would love to support it but all in all it comes down to
implementation here for me, so I'd rather do it in a separate
RFC.

If you meant accepting `function(string $foo){}` as an argument
of `callable(int)` parameter without coercing then this would
be impossible due the fact that this all is context-dependent.
Which means that the function which got `function(string $foo){}`
in place of `callable(int)` could itself be strict-mode
and when it would call this function it would raise a TypeError.


On Mon, 23 May 2016 20:05:50 +0300, Bob Weinand   
wrote:



Hey,

I have a question regarding strict/weak types.

Currently, you cannot pass a callable function(string $foo) {} to a  
signature requiring (callable(int)), if I understood the code correctly.


But weak types actually should allow that as it's totally fine to pass  
an integer to a string in weak mode.


Is there any particular reason to this seemingly arbitrary restriction?

Bob


Am 23.05.2016 um 16:27 schrieb Nikita Nefedov :

Evening internals,

With this message I'd like to go to vote
with the Callable prototypes RFC targeted at 7.1:
https://wiki.php.net/rfc/callable-types

We've renamed it (previously was "Callable types") as RFC names often
dictate how users will call the feature and I want it to be more
accurate/descriptive.

Also the reflection part was added although I'm short on time currently,
so implementation for that will be ready later. (speaking of  
implementation,

it also currently doesn't use cache_slots - also something I'll add when
I have a little bit of time)


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Vote] Callable types (now: Callable prototypes)

[Nikita Nefedov]

> On 23 May 2016, at 19:31, Levi Morrison  wrote:
> 
>> On Mon, May 23, 2016 at 8:27 AM, Nikita Nefedov  wrote:
>> Evening internals,
>> 
>> With this message I'd like to go to vote
>> with the Callable prototypes RFC targeted at 7.1:
>> https://wiki.php.net/rfc/callable-types
>> 
>> We've renamed it (previously was "Callable types") as RFC names often
>> dictate how users will call the feature and I want it to be more
>> accurate/descriptive.
>> 
>> Also the reflection part was added although I'm short on time currently,
>> so implementation for that will be ready later. (speaking of implementation,
>> it also currently doesn't use cache_slots - also something I'll add when
>> I have a little bit of time)
>> 
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> A quick question before I vote: do callable prototypes allow for
> default parameters in the signature? There are examples for having a
> function passed that has a default parameters but I am not seeing it
> anywhere in the callable prototype definition so I thought I'd ask.

Hey Levi,

Although it could be done as a later RFC, my stance on it is that default 
values don't belong to the prototype of the function.

Why I think that callable typehint doesn't need default values for params is: 
you either need this parameter to exist and even if there are cases where you'd 
like to pass some kind of 'default' value implicitly, you as a caller shouldn't 
impose on the callee responsibility to have this same value in his definition 
and instead just pass your argument explicitly... or if you don't need this 
parameter (as in you don't plan to pass anything explicitly) then you should 
just ask for a function without this parameter as there is clearly no need for 
it at all.

Moreover I would argue interfaces have it wrong here too: the fact that default 
values are part of an interface yet their invariance is not enforced, yields an 
interesting sort of possible LSP violation. F.e. if we have an interface Logger 
(a completely unreal example but it shows what can go wrong) with function 
'log($message, $level = LOG_DEBUG);' and a funny implementation that decided to 
change default value of $level to LOG_ALERT, then all callers of Logger#log who 
relied on the fact that level if not specified, will be LOG_DEBUG, who also 
happen to get the funny implementation of Logger will produce unneeded noise in 
the logs with their alert level messages which were intended to be debug 
messages :(
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Vote] Callable types (now: Callable prototypes)

[Bob Weinand]

Hey,

I have a question regarding strict/weak types.

Currently, you cannot pass a callable function(string $foo) {} to a signature 
requiring (callable(int)), if I understood the code correctly.

But weak types actually should allow that as it's totally fine to pass an 
integer to a string in weak mode.

Is there any particular reason to this seemingly arbitrary restriction?

Bob

> Am 23.05.2016 um 16:27 schrieb Nikita Nefedov :
> 
> Evening internals,
> 
> With this message I'd like to go to vote
> with the Callable prototypes RFC targeted at 7.1:
> https://wiki.php.net/rfc/callable-types
> 
> We've renamed it (previously was "Callable types") as RFC names often
> dictate how users will call the feature and I want it to be more
> accurate/descriptive.
> 
> Also the reflection part was added although I'm short on time currently,
> so implementation for that will be ready later. (speaking of implementation,
> it also currently doesn't use cache_slots - also something I'll add when
> I have a little bit of time)
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Vote] Callable types (now: Callable prototypes)

[Levi Morrison]

On Mon, May 23, 2016 at 8:27 AM, Nikita Nefedov  wrote:
> Evening internals,
>
> With this message I'd like to go to vote
> with the Callable prototypes RFC targeted at 7.1:
> https://wiki.php.net/rfc/callable-types
>
> We've renamed it (previously was "Callable types") as RFC names often
> dictate how users will call the feature and I want it to be more
> accurate/descriptive.
>
> Also the reflection part was added although I'm short on time currently,
> so implementation for that will be ready later. (speaking of implementation,
> it also currently doesn't use cache_slots - also something I'll add when
> I have a little bit of time)
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

A quick question before I vote: do callable prototypes allow for
default parameters in the signature? There are examples for having a
function passed that has a default parameters but I am not seeing it
anywhere in the callable prototype definition so I thought I'd ask.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: "finally" handling refactoring (Bug #72213)

[Nikita Popov]

On Mon, May 23, 2016 at 1:25 PM, Dmitry Stogov  wrote:

> Thanks for review.
>
> Both problems should be fixed now
> https://gist.github.com/dstogov/0a809891c6a3ac3fac4bd0d9711dd330
>
> Do you see any other problems or a better way to fix this?
>
Your fix for DISCARD_EXCEPTION does not look right to me. It will discard
all exceptions too early. For example:

function test() {
try {
throw new Exception(1);
} finally {
try {
try {
} finally {
return 42;
}
} finally {
throw new Exception(2);
}
}
}

test();

This will now not chain exception 1 and 2, because exception 1 is discarded
at the return statement.

I think this should be handled the same way we do the fast_call dispatch on
return, i.e. when we pop the FAST_CALL from the loop var stack we should
replace it with a DISCARD_EXCEPTION and then pop it after the finally. This
should generate all the necessary DISCARD_EXCEPTION opcodes, and in the
right order.

Nikita

[PHP-DEV] [RFC] [Vote] Callable types (now: Callable prototypes)

[Nikita Nefedov]

Evening internals,

With this message I'd like to go to vote
with the Callable prototypes RFC targeted at 7.1:
https://wiki.php.net/rfc/callable-types

We've renamed it (previously was "Callable types") as RFC names often
dictate how users will call the feature and I want it to be more
accurate/descriptive.

Also the reflection part was added although I'm short on time currently,
so implementation for that will be ready later. (speaking of  
implementation,

it also currently doesn't use cache_slots - also something I'll add when
I have a little bit of time)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Dmitry Stogov]

Yeah "float". It works :)


From: Niklas Keller 
Sent: Monday, May 23, 2016 4:46:59 PM
To: Dmitry Stogov; Joe Watkins; PHP internals; Phil Sturgeon
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties

Dmitry Stogov > schrieb am Mo., 23. Mai 
2016 14:48:
Should this work?

x = 5;
?>

Currently this leads to PHP Fatal error:  Uncaught TypeError: Typed property 
C::$x must be an instance of double, integer used in 
/home/dmitry/php/php-master/CGI-DEBUG/prop.php:6

Do you mean "float"?




From: Joe Watkins >
Sent: Friday, May 20, 2016 9:05:34 AM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties

Morning internals,

Since we have our answer on nullable types, typed properties can now go
to vote.

https://wiki.php.net/rfc/typed-properties#vote

Note that, support for nullability as RFC'd will be merged when the
implementation for nullable_types is merged into master.

Please participate.

Cheers
Joe

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Niklas Keller]

Dmitry Stogov  schrieb am Mo., 23. Mai 2016 14:48:

> Should this work?
>
>  class C {
> public double $x;
> }
> $o = new C;
> $o->x = 5;
> ?>
>
> Currently this leads to PHP Fatal error:  Uncaught TypeError: Typed
> property C::$x must be an instance of double, integer used in
> /home/dmitry/php/php-master/CGI-DEBUG/prop.php:6
>

Do you mean "float"?


>
> 
> From: Joe Watkins 
> Sent: Friday, May 20, 2016 9:05:34 AM
> To: PHP internals; Phil Sturgeon
> Subject: [PHP-DEV] [RFC][Vote] Typed Properties
>
> Morning internals,
>
> Since we have our answer on nullable types, typed properties can now go
> to vote.
>
> https://wiki.php.net/rfc/typed-properties#vote
>
> Note that, support for nullability as RFC'd will be merged when the
> implementation for nullable_types is merged into master.
>
> Please participate.
>
> Cheers
> Joe
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[lp_benchmark_robot]

Results for project PHP master, build date 2016-05-23 06:28:15+03:00
commit: 0d62dfd
previous commit:4f077ae
revision date:  2016-05-22 00:05:06+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.18%  0.01%  0.50%  
  7.12%
:-|   Drupal 7.36 cgi -T1  0.13% -0.05%  4.80%  
  5.04%
:-|   MediaWiki 1.23.9 cgi -T5000  0.13%  0.13%  0.54%  
  3.55%
:-|   bench.php cgi -T100  0.10% -0.04% 27.63%  
 -2.42%
:-|  micro_bench.php cgi -T10  0.20%  0.03%  5.15%  
  3.36%
:-|  mandelbrot.php cgi -T100  0.81% -0.21% 30.02%  
  7.37%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/neutral-benchmark-results-for-php-master-2016-05-23/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Dmitry Stogov]

Should this work?

x = 5;
?>

Currently this leads to PHP Fatal error:  Uncaught TypeError: Typed property 
C::$x must be an instance of double, integer used in 
/home/dmitry/php/php-master/CGI-DEBUG/prop.php:6




From: Joe Watkins 
Sent: Friday, May 20, 2016 9:05:34 AM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties

Morning internals,

Since we have our answer on nullable types, typed properties can now go
to vote.

https://wiki.php.net/rfc/typed-properties#vote

Note that, support for nullability as RFC'd will be merged when the
implementation for nullable_types is merged into master.

Please participate.

Cheers
Joe

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Dmitry Stogov]

Hi Joe,


Unfortunately your solution with IS_TYPE_VERIFIED is not acceptable, because 
you update the source zval.


If the assigned value is a literal you change read-only memory and crash (with 
opcache.ptotect_memory=1)


a = 5;
?>


Thanks. Dmitry.




From: Joe Watkins 
Sent: Monday, May 23, 2016 1:16:22 PM
To: Julien Pauli
Cc: Stanislav Malyshev; Dmitry Stogov; PHP internals; Phil Sturgeon
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties

Morning internals,

I have improved the performance of the patch a little, here's the results 
of a bad run:

krakjoe@fiji:/usr/src/php-src$ sapi/cli/php -n prop.php
empty_loop 0.064
write_prop1()  0.0880.025
write_prop2()  0.0790.016
write_prop3()  0.0820.018

Total  0.314

There is going to be overhead, not the kind we can't minimize, or justify 
though.

Dmitry has said he'll review, and I'm hoping at least Laruence, Nikita, and 
Bob will do the same ...

We have many weeks to improve the implementation, I'm not going to merge 
anything that's obviously bad :)

Cheers
Joe


On Mon, May 23, 2016 at 10:54 AM, Julien Pauli 
> wrote:
On Mon, May 23, 2016 at 11:09 AM, Stanislav Malyshev
> wrote:
> Hi!
>
>> The performance effect of this implementation is terrible.
>>
>> Assignment to typed property is 2.3 times slower.
>> Assignment to untyped property in a class with typed properties is 1.8 times 
>> slower.
>>
>> See the benchmark
>> https://gist.github.com/dstogov/1b678712adeee51665cdd829195bb800
>
> This is not good. I wonder why these tests weren't made before the vote
> and results wheren't added in the RFC. Should we make it a standard
> practice to do so? Having 2x slowdown on each property access sounds
> like a bad idea.

The question is :
* should the vote be an idea-based vote, or integrate the code into the vote ?

My vote did not integrate the code, but the feature.

The idea is that if the RFC passes, then the feature is agreed, and we
still have some time to find a better implementation.
If we could not find one, then the feature should be abandoned or
post-poned until a new patch. If the new patch changes the
implementation, then the RFC should be reopened.

My thoughts.

Julien.Pauli

[PHP-DEV] Re: "finally" handling refactoring (Bug #72213)

[Dmitry Stogov]

Thanks for review.

Both problems should be fixed now 
https://gist.github.com/dstogov/0a809891c6a3ac3fac4bd0d9711dd330

Do you see any other problems or a better way to fix this?


Thanks. Dmitry.


From: Nikita Popov 
Sent: Friday, May 20, 2016 4:54:07 PM
To: Dmitry Stogov
Cc: Xinchen Hui; internals
Subject: Re: "finally" handling refactoring (Bug #72213)

On Fri, May 20, 2016 at 2:07 PM, Dmitry Stogov 
> wrote:

hi,


Please review the path 
https://gist.github.com/dstogov/0a809891c6a3ac3fac4bd0d9711dd330


I hope, it should completely fix https://bugs.php.net/bug.php?id=72213


I'm going to commit this on Monday.


Thanks. Dmitry.

>From a quick look:

https://gist.github.com/dstogov/0a809891c6a3ac3fac4bd0d9711dd330#file-bug72213-diff-L74
 => should this be orig_try_catch_offset?

https://gist.github.com/dstogov/0a809891c6a3ac3fac4bd0d9711dd330#file-bug72213-diff-L303
 => This assumes that either there's a catch block or a finally block to go to. 
However, if we're in the catch block of a try/catch (without finally) that may 
not be true.

Also, this still leaks one exception :(

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

[Rowan Collins]

On 20/05/2016 07:05, Joe Watkins wrote:

Morning internals,

Since we have our answer on nullable types, typed properties can now go
to vote.

https://wiki.php.net/rfc/typed-properties#vote

Note that, support for nullability as RFC'd will be merged when the
implementation for nullable_types is merged into master.

Please participate.

Cheers
Joe



I'm surprised at how popular this RFC has been; not because I think it's 
a bad thing per se, but I thought it would be more controversial.


I do still think PHP should have a proper road map for typing features, 
though. The issues around typed references in this RFC are a good 
example of how having an increasing number of silos where type 
enforcement takes place leads to odd inconsistencies and limitations. It 
would be nice to have some idea of what the eventual aim is - even if we 
don't know how yet, is the aim in people's minds for "optional typing" 
to extend throughout the language?


This would also help with performance considerations - if type-checking 
is going to become a more important concept in the language, the engine 
should move in a direction which will make that easier, and that may 
affect optimisation decisions.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Joe Watkins]

Morning internals,

I have improved the performance of the patch a little, here's the
results of a bad run:

krakjoe@fiji:/usr/src/php-src$ sapi/cli/php -n prop.php
empty_loop 0.064
write_prop1()  0.0880.025
write_prop2()  0.0790.016
write_prop3()  0.0820.018

Total  0.314

There is going to be overhead, not the kind we can't minimize, or
justify though.

Dmitry has said he'll review, and I'm hoping at least Laruence, Nikita,
and Bob will do the same ...

We have many weeks to improve the implementation, I'm not going to
merge anything that's obviously bad :)

Cheers
Joe


On Mon, May 23, 2016 at 10:54 AM, Julien Pauli  wrote:

> On Mon, May 23, 2016 at 11:09 AM, Stanislav Malyshev
>  wrote:
> > Hi!
> >
> >> The performance effect of this implementation is terrible.
> >>
> >> Assignment to typed property is 2.3 times slower.
> >> Assignment to untyped property in a class with typed properties is 1.8
> times slower.
> >>
> >> See the benchmark
> >> https://gist.github.com/dstogov/1b678712adeee51665cdd829195bb800
> >
> > This is not good. I wonder why these tests weren't made before the vote
> > and results wheren't added in the RFC. Should we make it a standard
> > practice to do so? Having 2x slowdown on each property access sounds
> > like a bad idea.
>
> The question is :
> * should the vote be an idea-based vote, or integrate the code into the
> vote ?
>
> My vote did not integrate the code, but the feature.
>
> The idea is that if the RFC passes, then the feature is agreed, and we
> still have some time to find a better implementation.
> If we could not find one, then the feature should be abandoned or
> post-poned until a new patch. If the new patch changes the
> implementation, then the RFC should be reopened.
>
> My thoughts.
>
> Julien.Pauli
>

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

[Julien Pauli]

On Mon, May 23, 2016 at 11:09 AM, Stanislav Malyshev
 wrote:
> Hi!
>
>> The performance effect of this implementation is terrible.
>>
>> Assignment to typed property is 2.3 times slower.
>> Assignment to untyped property in a class with typed properties is 1.8 times 
>> slower.
>>
>> See the benchmark
>> https://gist.github.com/dstogov/1b678712adeee51665cdd829195bb800
>
> This is not good. I wonder why these tests weren't made before the vote
> and results wheren't added in the RFC. Should we make it a standard
> practice to do so? Having 2x slowdown on each property access sounds
> like a bad idea.

The question is :
* should the vote be an idea-based vote, or integrate the code into the vote ?

My vote did not integrate the code, but the feature.

The idea is that if the RFC passes, then the feature is agreed, and we
still have some time to find a better implementation.
If we could not find one, then the feature should be abandoned or
post-poned until a new patch. If the new patch changes the
implementation, then the RFC should be reopened.

My thoughts.

Julien.Pauli

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Ivan Enderlin]

I vote no for the same performance reason, but the whole Hoa's community 
is agree with the RFC.


Thanks for the hard work!

On 23/05/16 11:02, Dmitry Stogov wrote:

I appreciate the work done by Joe, but I vote "no", because the implementation 
is not good enough yet

- it's incompatible with opcache (may be it's not a big problem to fix this)
- typed properties assignment is going to be 2-3 times slower ($obj->x += 2; is 
3 times slower)
- the patch makes slight negative effect even for untyped properties

- the proposed behavior for uninitialized typed properties assumes that they have to be 
checked on each "read". This checks will have to be performed even in native 
JITed code. I don't see a reason for typing if we have to perform check on each read 
anyway.

Thanks. Dmitry.

From: Dmitry Stogov 
Sent: Monday, May 23, 2016 11:30:09 AM
To: Joe Watkins; PHP internals; Phil Sturgeon
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties

Hi Joe,

The performance effect of this implementation is terrible.

Assignment to typed property is 2.3 times slower.
Assignment to untyped property in a class with typed properties is 1.8 times 
slower.

See the benchmark
https://gist.github.com/dstogov/1b678712adeee51665cdd829195bb800

Thanks. Dmitry.

From: Joe Watkins 
Sent: Friday, May 20, 2016 9:05:34 AM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties

Morning internals,

 Since we have our answer on nullable types, typed properties can now go
to vote.

 https://wiki.php.net/rfc/typed-properties#vote

 Note that, support for nullability as RFC'd will be merged when the
implementation for nullable_types is merged into master.

 Please participate.

Cheers
Joe

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Stanislav Malyshev]

Hi!

> The performance effect of this implementation is terrible.
> 
> Assignment to typed property is 2.3 times slower.
> Assignment to untyped property in a class with typed properties is 1.8 times 
> slower.
> 
> See the benchmark
> https://gist.github.com/dstogov/1b678712adeee51665cdd829195bb800

This is not good. I wonder why these tests weren't made before the vote
and results wheren't added in the RFC. Should we make it a standard
practice to do so? Having 2x slowdown on each property access sounds
like a bad idea.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Dmitry Stogov]

I appreciate the work done by Joe, but I vote "no", because the implementation 
is not good enough yet

- it's incompatible with opcache (may be it's not a big problem to fix this)
- typed properties assignment is going to be 2-3 times slower ($obj->x += 2; is 
3 times slower)
- the patch makes slight negative effect even for untyped properties

- the proposed behavior for uninitialized typed properties assumes that they 
have to be checked on each "read". This checks will have to be performed even 
in native JITed code. I don't see a reason for typing if we have to perform 
check on each read anyway.

Thanks. Dmitry.

From: Dmitry Stogov 
Sent: Monday, May 23, 2016 11:30:09 AM
To: Joe Watkins; PHP internals; Phil Sturgeon
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties

Hi Joe,

The performance effect of this implementation is terrible.

Assignment to typed property is 2.3 times slower.
Assignment to untyped property in a class with typed properties is 1.8 times 
slower.

See the benchmark
https://gist.github.com/dstogov/1b678712adeee51665cdd829195bb800

Thanks. Dmitry.

From: Joe Watkins 
Sent: Friday, May 20, 2016 9:05:34 AM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties

Morning internals,

Since we have our answer on nullable types, typed properties can now go
to vote.

https://wiki.php.net/rfc/typed-properties#vote

Note that, support for nullability as RFC'd will be merged when the
implementation for nullable_types is merged into master.

Please participate.

Cheers
Joe

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Dmitry Stogov]

Hi Joe,

The performance effect of this implementation is terrible.

Assignment to typed property is 2.3 times slower.
Assignment to untyped property in a class with typed properties is 1.8 times 
slower.

See the benchmark
https://gist.github.com/dstogov/1b678712adeee51665cdd829195bb800

Thanks. Dmitry.

From: Joe Watkins 
Sent: Friday, May 20, 2016 9:05:34 AM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties

Morning internals,

Since we have our answer on nullable types, typed properties can now go
to vote.

https://wiki.php.net/rfc/typed-properties#vote

Note that, support for nullability as RFC'd will be merged when the
implementation for nullable_types is merged into master.

Please participate.

Cheers
Joe

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Exception::getLine()

[Julien Pauli]

On Sat, May 21, 2016 at 8:16 PM, Rasmus Schultz  wrote:
> Alright, so forget my comparison with other languages.
>
> My other points remain:
>
> Presently, "throw new" is treated as though it was one statement.
> That's not the case. We have deferred throws and factory methods for
> exceptions, and we have re-throws, so collecting the stack-trace at
> construction time doesn't work.
>
> The construction site would only be relevant if "throw new" was in
> deed a single statement.
>
> Recording the actual throw site is clearly the goal - the current
> implementation is betting on "throw" and "new" happening at the same
> site, which is merely circumstance.
>
> Ideally, an Exception should collect another stack trace for each
> successive throw, which would enable you to trace not only the
> original site, but the flow through any exception-handlers that might
> have re-thrown the same Exception.
>
> As is, there is no information collected on throw, and thereby no
> evidence or record of possible re-throws - on top of the fact that you
> may be collecting and looking at bogus stack-traces from factory
> methods or exception mappers.
>
>
> On Fri, May 20, 2016 at 11:06 AM, Rowan Collins  
> wrote:
>> On 20/05/2016 08:22, Niklas Keller wrote:
>>>
>>> 2016-05-20 4:13 GMT+02:00 Jesse Schalken :

 The top frame is the construction (get_error) and the site of the throw
 (do_throw) doesn't appear in the stack at all.

>>>
>>> The comparison with JavaScript isn't a good one, since you can throw
>>> everything in JS. If they didn't provide the stack trace upon throw, you
>>> would not have a stack trace at all if you throw a plain string.
>>>
>>
>>
>> That explanation justifies completely the opposite behaviour to what Jesse
>> described.
>>
>> According to MDN [1] the "stack" property is completley unstandardised, and
>> some engines may indeed populate it on throw, but there's no hint on that
>> page that they'll attach it to anything not constructed as an Error.
>>
>> So it's not a great comparison for either side (note that it was originally
>> brought up by Rasmus as an example where it *does* come from the throw site)
>> because the language doesn't actually guarantee you a stack trace at all.
>>
>> [1]
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/stack
>>
>> Regards,
>> --
>> Rowan Collins
>> [IMSoP]
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hi.

I explained that in my article detailing Exceptions from internal ,
http://jpauli.github.io/2015/04/09/exceptional-php.html

I admit it would be more logical to collect the trace in the
ZEND_THROW Opcode instead of in the create_handler of the Exception
class.

That would break backtraces, but we already broke them in PHP 7.0
So we could think about it for a 8.0 ideally , or a 7.1 ; I'm not
sure. Anyway, that needs more debate ;-)



Julien.Pauli

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7 CSPRNG - block on /dev/random?

[Julien Pauli]

On Sun, May 22, 2016 at 7:04 AM, Stanislav Malyshev  wrote:
> Hi!
>
>> Question: Is there a nonzero chance of a PHP application running at boot
>> time on an older GNU/Linux machine? If so, should we adopt this "unseeded
>> CSPRNG" mitigation employed by libsodium for ancient Linux kernels?
>>
>> https://github.com/jedisct1/libsodium/issues/374
>> https://github.com/jedisct1/libsodium/commit/c752eb55d9e9992bc38e7790128953427aa0a89f
>>
>> This could be done as a security patch for PHP 7.0.x if there's any concern
>> about startup entropy e.g. on embedded devices.
>
> If they're running Linux kernel that deserves to be called "ancient",
> wouldn't they also run old PHP? In any case, from the problem
> description, it looks like the problem happens "on early boot". I don't
> see how you can get to run PHP code before you get way, way beyond early
> boot.
>
>> I'm not aware of any such projects being written in PHP, so my intuition is
>> this is a non-issue for us.
>
> I agree, this appears to be non-issue for PHP.

Same thinking here => we're not concerned.


Julien.Pauli

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Dmitry Stogov]

The patch "corrupts" opcache shared memory.
PHP crashes with opcache.protect_memory=1.

$ USE_ZEND_ALLOC=0 valgrind sapi/cli/php -d opcache.protect_memory=1 
../Zend/tests/type_declarations/typed_properties_027.php
==900== Memcheck, a memory error detector
==900== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==900== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==900== Command: sapi/cli/php 
../Zend/tests/type_declarations/typed_properties_027.php
==900==
==900==
==900== Process terminating with default action of signal 11 (SIGSEGV)
==900==  Bad permissions for mapped region at address 0xF00FFBC8
==900==at 0x86391FE: zend_verify_weak_scalar_type_hint (zend_execute.c:725)
==900==by 0x8639833: zend_verify_scalar_property_type (zend_execute.c:869)
==900==by 0x8639C2B: zend_verify_property_type (zend_execute.c:938)
==900==by 0x862E46D: zend_std_write_property (zend_object_handlers.c:753)
==900==by 0x8685102: ZEND_ASSIGN_OBJ_SPEC_CV_CONST_OP_DATA_CONST_HANDLER 
(zend_vm_execute.h:42160)
==900==by 0x863F91D: execute_ex (zend_vm_execute.h:426)
==900==by 0x863F9D2: zend_execute (zend_vm_execute.h:471)
==900==by 0x85F38B4: zend_execute_scripts (zend.c:1427)
==900==by 0x85832B7: php_execute_script (main.c:2492)
==900==by 0x86AE2D8: do_cli (php_cli.c:982)
==900==by 0x86AEF42: main (php_cli.c:1352)
==900==






From: Joe Watkins 
Sent: Friday, May 20, 2016 9:05:34 AM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties

Morning internals,

Since we have our answer on nullable types, typed properties can now go
to vote.

https://wiki.php.net/rfc/typed-properties#vote

Note that, support for nullability as RFC'd will be merged when the
implementation for nullable_types is merged into master.

Please participate.

Cheers
Joe

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] base64_decode is buggy, what to fix?

[Niklas Keller]

Completely missing padding shouldn't fail, it's often removed to save space
or when base64 is converted to base64url.

Joe Watkins  schrieb am Mo., 23. Mai 2016 06:59:

> Morning,
>
> Would it be possible to open a PR that fixes the programming errors,
> such as oob read, and the strange flow of the subsequent block ?
>
> Assuming those fixes don't effect normal usage, I see no reason why
> that can't be merged immediately.
>
> When it comes to changing the behaviour, that needs a little more
> discussion I think, and I wait to see what others think about those
> changes.
>
> Cheers
> Joe
>
> On Mon, May 23, 2016 at 1:52 AM, Yasuo Ohgaki  wrote:
>
> > Hi Lauri,
> >
> > On Sun, May 22, 2016 at 7:56 PM, Lauri Kenttä 
> > wrote:
> > >
> > > Suggestions?
> >
> > IMHO
> >
> > Return FALSE for any invalid input when strict mode is on.
> > Enable strict mode by default.
> > Keep current behavior when strict mode is off.
> >
> > would be the best.
> >
> > Regards,
> >
> > --
> > Yasuo Ohgaki
> > yohg...@ohgaki.net
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>