[PHP-DEV] BAD Benchmark Results for PHP Master 2017-07-28

[lp_benchmark_robot]

Results for project PHP master, build date 2017-07-28 13:47:43-07:00
commit: f9c3ee9
previous commit:d615a92
revision date:  2017-07-28 22:18:51+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.23%  0.10%  3.83%  
  9.38%
:-|   Drupal 7.36 cgi -T1  0.21%  0.19%  3.34%  
  6.05%
:-|   MediaWiki 1.23.9 cgi -T5000  0.07%  0.30%  3.56%  
  3.80%
:-|   bench.php cgi -T100  0.01%  0.75% 45.68%  
  1.96%
:-|  micro_bench.php cgi -T10  0.01% -0.21% 28.63%  
  2.52%
:-(  mandelbrot.php cgi -T100  0.02% -4.64% 42.75%  
  3.41%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/bad-benchmark-results-for-php-master-2017-07-28/

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] Changes to SuperGlobals for PHP 8 (was: something about session_start...)

[Rowan Collins]

Hi Sara,

>>> On Fri, Jul 28, 2017 at 5:45 PM, Sara Golemon 
>wrote:
 ftr; I'd vote in favor of several BC breaking things to do with
 autoglobals, among them:

 * Make them objects (though ArrayAccess based for less hostile BC
 breakage)
 * Make most of them read-only (offsetGet(), but no offsetSet)
 * Make $_SESSION[...] access produce an error or auto-start the
>session

Yep, this is pretty much what I had in mind when I made that passing remark, 
but didn't want to derail the thread. Now it has its own thread, however, I'm 
going to argue against myself and say why I think this is the wrong direction. 
;)

The obvious downside of changing request vars to read only is the huge body of 
code that writes to them. This isn't all bad code: as rhsoft points out, 
testing any code that *reads* those vars necessarily requires the harness to 
write to them; and a common way to *prevent* reading them is to overwrite them 
with empty values.

More importantly, though, it's papering over the problem, which is that request 
information shouldn't be global. There are other barriers to a threaded, 
event-based SAPI becoming core and default, but a scoped request representation 
would be high up the todo list.

There was mention a while ago of discussion in the Python community of 
replacing WSGI with an even more flexible interface for the HTTP2 era, 
supporting worker and server push models as well as request-response. The 
suggestion was that PHP could learn from or even collaborate on that model. 
Does anyone know its status?

Obviously, that's a much more ambitious project, but if we're talking 10 years 
to phase in a breaking change, it would be good to at least attempt some 
future-proofing, rather than just adding a few restrictions which were missed 
10 years ago, and implicitly extending the lifetime of the concept of global 
request data.

On a slight tangent, I consider $_SERVER to be a broken pile of "we'll just 
shove this in here and hope for the best", and I will oppose any attempt to 
convert it into an object which doesn't reorganize its keys to be sane, 
documented, and as cross-platform as the SAPI layer can make it. :P

Regards,

-- 
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] Changes to SuperGlobals for PHP 8 (was: something about session_start...)

[Johannes Schlüter]

On Fr, 2017-07-28 at 11:11 -0400, Sara Golemon wrote:
> I'm sure there will be many strong opinions on this, but let's move
> this to a new thread. :D

Language-wise, I think, refactoring that system would be good. I guess
a refactoring is a register_globals-like project, which took 10 years
from first deprecations to final removal, since many people abuse it
and parameter handling is core to PHP.

For read-only access we already have an API: filter_input() etc., maybe
the interface could be made "nicer." GitHub shows 267,811 hits for
that, but only few "real" "productive" cases. From tutorials etc. this
doesn't seem to be widely accepted.
https://github.com/search?l=PHP=1=filter_input=Code=%E2%9
C%93

johannes


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

Re: [PHP-DEV] Changes to SuperGlobals for PHP 8

[Rick Widmer]

On 7/28/2017 10:42 AM, li...@rhsoft.net wrote:



Am 28.07.2017 um 18:21 schrieb Kalle Sommer Nielsen:

2017-07-28 17:11 GMT+02:00 Sara Golemon :

I'm sure there will be many strong opinions on this, but let's move
this to a new thread. :D

1. This would be an 8.0 change as it does represent a significant BC 
change.

2. We can discuss the possibility of INI options or other mitigation
strategies for misbehaving code bases (and they do exist).
3. I'm definitely not decided on what I'd like from default session
behavior. An error isn't out of the question, for sure.


I for one thing it makes a lot of sense to make superglobals
read-only, writing to them seems more like a hack anyway and should be
avoided


wrong question!

the right questions are

* are you fored to do so
* are you harmed by the possibility

and only if you can answer both with "yes" it's worth to cosindr changes 
breaking a ton of perfect working code




What he said.  That would break almost everything I've written.

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

Re: [PHP-DEV] Changes to SuperGlobals for PHP 8

[li...@rhsoft.net]

Am 28.07.2017 um 18:21 schrieb Kalle Sommer Nielsen:

2017-07-28 17:11 GMT+02:00 Sara Golemon :

I'm sure there will be many strong opinions on this, but let's move
this to a new thread. :D

1. This would be an 8.0 change as it does represent a significant BC change.
2. We can discuss the possibility of INI options or other mitigation
strategies for misbehaving code bases (and they do exist).
3. I'm definitely not decided on what I'd like from default session
behavior. An error isn't out of the question, for sure.


I for one thing it makes a lot of sense to make superglobals
read-only, writing to them seems more like a hack anyway and should be
avoided


wrong question!

the right questions are

* are you fored to do so
* are you harmed by the possibility

and only if you can answer both with "yes" it's worth to cosindr changes 
breaking a ton of perfect working code


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

Re: [PHP-DEV] Changes to SuperGlobals for PHP 8

[Paul Jones]

> On Jul 28, 2017, at 10:11, Sara Golemon  wrote:
> 
> 3. I'm definitely not decided on what I'd like from default session
> behavior. An error isn't out of the question, for sure.

If this kind of big change is being contemplated, I would very much be in favor 
of decoupling the various combined elements of sessions. In particular, 
decoupling the auto-reading and auto-sending of cookies from the storage 
interactions.

Also, the "request" extension (and its related RFC) may have some use here, as 
it attempts to address the readable nature of superglobals.

- http://pecl.php.net/package/request
- https://wiki.php.net/rfc/request_response


-- 
Paul M. Jones
pmjone...@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php




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

Re: [PHP-DEV] Changes to SuperGlobals for PHP 8 (was: something about session_start...)

[Kalle Sommer Nielsen]

2017-07-28 17:11 GMT+02:00 Sara Golemon :
> I'm sure there will be many strong opinions on this, but let's move
> this to a new thread. :D
>
> 1. This would be an 8.0 change as it does represent a significant BC change.
> 2. We can discuss the possibility of INI options or other mitigation
> strategies for misbehaving code bases (and they do exist).
> 3. I'm definitely not decided on what I'd like from default session
> behavior. An error isn't out of the question, for sure.

I for one thing it makes a lot of sense to make superglobals
read-only, writing to them seems more like a hack anyway and should be
avoided


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

[PHP-DEV] Changes to SuperGlobals for PHP 8 (was: something about session_start...)

[Sara Golemon]

On Fri, Jul 28, 2017 at 11:03 AM, li...@rhsoft.net  wrote:
>> On Fri, Jul 28, 2017 at 5:45 PM, Sara Golemon  wrote:
>>> ftr; I'd vote in favor of several BC breaking things to do with
>>> autoglobals, among them:
>>>
>>> * Make them objects (though ArrayAccess based for less hostile BC
>>> breakage)
>>> * Make most of them read-only (offsetGet(), but no offsetSet)
>>> * Make $_SESSION[...] access produce an error or auto-start the session
>>>
>>> I've seen too many codebases abuse GPCER vars as a generic storage
>>> location because "globals are bad, but this is good because it doesn't
>>> include the word global".  As a performance issue, the runtime has to
>>> assume autoglobals are inherently volatile and could change on a whim
>>> at any moment (much like $http_response_headers).  Restricting their
>>> mutability would be a win.  The request globals could probably also be
>>> optimized fairly significantly.
>>>
>>> If anyone agrees, I'm willing to RFC it.  If not, I'll continue living
>>> with it. :D
>>>
>>
>> Yes, please!
>
>
> raise a warning when write to $_SESSION without a session_start()
>
> make a implicit autostart - *for sure not* this would only produce hidden
> errors or later warnings when you rely on session params and introduce more
> problems that it solves because clients don't like the same cookies ith
> different params
>
> make POST/GET/SERVER readonly - only when you refactor a 25 line code
> base as well as deplyed code which relies on the framework did the right
> thing with them previously :-)
>
>
I'm sure there will be many strong opinions on this, but let's move
this to a new thread. :D

1. This would be an 8.0 change as it does represent a significant BC change.
2. We can discuss the possibility of INI options or other mitigation
strategies for misbehaving code bases (and they do exist).
3. I'm definitely not decided on what I'd like from default session
behavior. An error isn't out of the question, for sure.

-Sara

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

Re: [PHP-DEV] session_start() should not reset $_SESSIOn if it's not empty

[li...@rhsoft.net]

Am 28.07.2017 um 16:48 schrieb Andrey Andreev:

Hi,

On Fri, Jul 28, 2017 at 5:45 PM, Sara Golemon  wrote:


ftr; I'd vote in favor of several BC breaking things to do with
autoglobals, among them:

* Make them objects (though ArrayAccess based for less hostile BC breakage)
* Make most of them read-only (offsetGet(), but no offsetSet)
* Make $_SESSION[...] access produce an error or auto-start the session

I've seen too many codebases abuse GPCER vars as a generic storage
location because "globals are bad, but this is good because it doesn't
include the word global".  As a performance issue, the runtime has to
assume autoglobals are inherently volatile and could change on a whim
at any moment (much like $http_response_headers).  Restricting their
mutability would be a win.  The request globals could probably also be
optimized fairly significantly.

If anyone agrees, I'm willing to RFC it.  If not, I'll continue living
with it. :D



Yes, please!


raise a warning when write to $_SESSION without a session_start()

make a implicit autostart - *for sure not* this would only produce 
hidden errors or later warnings when you rely on session params and 
introduce more problems that it solves because clients don't like the 
same cookies ith different params


make POST/GET/SERVER readonly - only when you refactor a 25 line 
code base as well as deplyed code which relies on the framework did the 
right thing with them previously :-)


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

Re: [PHP-DEV] session_start() should not reset $_SESSIOn if it's not empty

[Andrey Andreev]

Hi,

On Fri, Jul 28, 2017 at 5:45 PM, Sara Golemon  wrote:
>
> ftr; I'd vote in favor of several BC breaking things to do with
> autoglobals, among them:
>
> * Make them objects (though ArrayAccess based for less hostile BC breakage)
> * Make most of them read-only (offsetGet(), but no offsetSet)
> * Make $_SESSION[...] access produce an error or auto-start the session
>
> I've seen too many codebases abuse GPCER vars as a generic storage
> location because "globals are bad, but this is good because it doesn't
> include the word global".  As a performance issue, the runtime has to
> assume autoglobals are inherently volatile and could change on a whim
> at any moment (much like $http_response_headers).  Restricting their
> mutability would be a win.  The request globals could probably also be
> optimized fairly significantly.
>
> If anyone agrees, I'm willing to RFC it.  If not, I'll continue living
> with it. :D
>

Yes, please!

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

Re: [PHP-DEV] session_start() should not reset $_SESSIOn if it's not empty

[Sara Golemon]

On Fri, Jul 28, 2017 at 10:11 AM, Rowan Collins  wrote:
> On 28 July 2017 14:37:10 BST, "li...@rhsoft.net"  wrote:
>>(Arguably, all the other superglobals should be read only for the same
>>reason, but that would be a huge break now.)
>>
>>make them readonly would break my whole codebase
>
> Yes, I only meant that as an absolutely hypothetical "if I had a time machine 
> and could design it a different way...", I realise it would break everything 
> to change it now.
>
>
ftr; I'd vote in favor of several BC breaking things to do with
autoglobals, among them:

* Make them objects (though ArrayAccess based for less hostile BC breakage)
* Make most of them read-only (offsetGet(), but no offsetSet)
* Make $_SESSION[...] access produce an error or auto-start the session

I've seen too many codebases abuse GPCER vars as a generic storage
location because "globals are bad, but this is good because it doesn't
include the word global".  As a performance issue, the runtime has to
assume autoglobals are inherently volatile and could change on a whim
at any moment (much like $http_response_headers).  Restricting their
mutability would be a win.  The request globals could probably also be
optimized fairly significantly.

If anyone agrees, I'm willing to RFC it.  If not, I'll continue living
with it. :D

-Sara

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

Re: [PHP-DEV] session_start() should not reset $_SESSIOn if it's not empty

[Rowan Collins]

On 28 July 2017 14:37:10 BST, "li...@rhsoft.net"  wrote:
>(Arguably, all the other superglobals should be read only for the same
>reason, but that would be a huge break now.)
>
>make them readonly would break my whole codebase 

Yes, I only meant that as an absolutely hypothetical "if I had a time machine 
and could design it a different way...", I realise it would break everything to 
change it now.


>> If I understand you right, the scenario you describe is "I don't want
>to start a session yet, but if and when I do, I want to put this data
>into it". It feels like that could be adequately handled in userland
>with a wrapper object (or global var and functions if you prefer),
>which reads to and from $_SESSION when a session is open, but a a
>holding array when it's not yet.
>
>that don't work because at this point you don't know in userland if you
>started a completly new session which should be initialized with values
>for follow-up requests or use the existing values from a previous 
>request - at least not without writing ugly code

Do you mean like this?

session_start();
if ( ! $_SESSION['initialised'] ) {
$_SESSION['initialised'] = true;
foreach ( $this->session_init_vars as $var => $val ) {
$_SESSION[ $var ] = $val;
}
}


That should work as long as you don't run session_start() outside that 
function, and centralising that is already necessary to avoid "already started" 
errors.

Regards,

-- 
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] session_start() should not reset $_SESSIOn if it's not empty

[li...@rhsoft.net]

Am 28.07.2017 um 14:48 schrieb Rowan Collins:

On 27 July 2017 18:03:23 BST, "li...@rhsoft.net"  wrote:

if that could work in the way that session_start() keeps the current
state of $_SESSION if not empty it would be possible to put the
APCU-Read and if exit($apcu_content); before session_start() which
would
gain another 30% performance


I think that behaviour would confuse more people than it would help. If 
anything, it should be an error to access $_ SESSION if no session is currently 
open - if there is no session, the array has no meaning. (Arguably, all the 
other superglobals should be read only for the same reason, but that would be a 
huge break now.)


make them readonly would break my whole codebase including autotests and 
code-coverage tools because it is legit to as example fill 
$_SERVER['SERVER_NAME'] with specific informations to define a straight 
behavior when running in cli-test-mode instead wrap every basic thing in 
function calls - at the curretn state a core-cms cache-hit has a total 
of 32 funtion calls including PHP internal ones


hence that 3 bugreport are becoming a MAJOR PROBLEM because the system 
itself is so fast that under load after a short time you get problems 
with dattabase connections and with persistent connections because of 
the third one after the load is gone any strict-typed application jsut 
breaks horrible


https://bugs.php.net/bug.php?id=74971
https://bugs.php.net/bug.php?id=74970
https://bugs.php.net/bug.php?id=74967


If I understand you right, the scenario you describe is "I don't want to start a 
session yet, but if and when I do, I want to put this data into it". It feels like 
that could be adequately handled in userland with a wrapper object (or global var and 
functions if you prefer), which reads to and from $_SESSION when a session is open, but a 
a holding array when it's not yet.


that don't work because at this point you don't know in userland if you 
started a completly new session which should be initialized with values 
for follow-up requests or use the existing values from a previous 
request - at least not without writing ugly code


session_start() knows that and would only need a flag if it is desired 
to bail out as you said above or as for this case init the session with 
specific values



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

Re: [PHP-DEV] [RFC] Raise warnings for json_encode() and json_decode() issues

[Craig Duncan]

On 28 July 2017 at 12:46, Andrey Andreev  wrote:

>
> This is a long shot, but here's an idea: an OOP API throwing exceptions.
>
> Would require more work both to implement and use, but it would surely
> be less error-prone and there'd be no BC break.
>

Hi Andrey, Yes that would resolve all BC issues, however that wouldn't help
with new developers picking up the `json_*` functions and using them
dangerously.
As pointed out in the original thread, there are plenty of wrappers that
provide this feature, the problem is that core functions have a huge gotcha.

If we introduced a new API then we'd need to deprecate the `json_*`
functions to make users aware, which I imagine would be the most
contentious thing suggested thus far

Re: [PHP-DEV] [RFC] Raise warnings for json_encode() and json_decode() issues

[Andrey Andreev]

Hi,

On Fri, Jul 28, 2017 at 2:39 PM, Jakub Zelenka  wrote:
> On Fri, Jul 28, 2017 at 12:23 PM, Craig Duncan  wrote:
>
>> Hi Nikita,
>>
>> Thanks for your input. Would you vote yes for throwing an exception?
>>
>>
> Just to clarify exceptions are no go for 7.x. It would have to be 8.x and
> it would be a huge BC break so I'm quite confident that this will fail the
> vote!

This is a long shot, but here's an idea: an OOP API throwing exceptions.

Would require more work both to implement and use, but it would surely
be less error-prone and there'd be no BC break.

Cheers,
Andrey.

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

Re: [PHP-DEV] [RFC] Raise warnings for json_encode() and json_decode() issues

[Craig Duncan]

On 28 July 2017 at 12:36, Jakub Zelenka  wrote:

>
> Also it would break a big amount of code because in case of converting
> errors to exceptions, you start getting a different exception so it would
> have to be handled. I would call the whole proposal just a big BC break
> (I'm aware that we don't consider adding warnings as BC but in this case it
> is) for no benefit at all!
>
>
Hi Jakub, thanks for sharing you opinion.

While I agree there are BC concerns, I don't think it's accurate to say no
benefit at all. I regularly see new (and experienced) developers using
these functions without checking `json_last_error()`, trying to figure out
why the app is failing later without any warnings in the log can be very
difficult.

Re: [PHP-DEV] [RFC] Raise warnings for json_encode() and json_decode() issues

[Jakub Zelenka]

On Fri, Jul 28, 2017 at 12:23 PM, Craig Duncan  wrote:

> Hi Nikita,
>
> Thanks for your input. Would you vote yes for throwing an exception?
>
>
Just to clarify exceptions are no go for 7.x. It would have to be 8.x and
it would be a huge BC break so I'm quite confident that this will fail the
vote!

Re: [PHP-DEV] [RFC] Raise warnings for json_encode() and json_decode() issues

[Jakub Zelenka]

On Fri, Jul 28, 2017 at 11:59 AM, Craig Duncan  wrote:

> Hi internals.
>
> As my initial thread about introducing warnings to the JSON functions was
> not immediately flooded with disagreement I took the liberty of creating an
> RFC for official discussion.
>
> The proposal is to have `json_encode()` and `json_decode()` raise warnings
> whenever a failure occurs, instead of requiring the developer to call
> `json_last_error()` each time.
>
> The functionality of `json_last_error()` and `json_last_error_msg()` are
> unaffected and they can still be used in exactly the same way they are
> today
>
> https://wiki.php.net/rfc/json_encode_decode_errors
>
>
I don't think this is a good idea. Especially in case of json_decode the
invalid JSON comes from sources that user does not have any control and
can't prevent the fail. Emitting warning wouldn't be helpful and it would
just make it more difficult to handle such cases.

Also it would break a big amount of code because in case of converting
errors to exceptions, you start getting a different exception so it would
have to be handled. I would call the whole proposal just a big BC break
(I'm aware that we don't consider adding warnings as BC but in this case it
is) for no benefit at all!

Cheers

Jakub

Re: [PHP-DEV] [RFC] Raise warnings for json_encode() and json_decode() issues

[Craig Duncan]

Hi Nikita,

Thanks for your input. Would you vote yes for throwing an exception?


On 28 July 2017 at 12:07, Nikita Popov  wrote:

>
> Operations that are expected to fail should never generate warnings. We
> should not design functions such that their correct use requires the use of
> the error suppression operator.
>
> I certainly agree that the current situation is not good and that the json
> functions really ought to be throwing exceptions, but adding a warning now
> is only going to make this worse.
>
> Nikita
>
>

Re: [PHP-DEV] [RFC] Raise warnings for json_encode() and json_decode() issues

[Andrey Andreev]

Hi,

On Fri, Jul 28, 2017 at 1:59 PM, Craig Duncan  wrote:
> Hi internals.
>
> As my initial thread about introducing warnings to the JSON functions was
> not immediately flooded with disagreement I took the liberty of creating an
> RFC for official discussion.
>
> The proposal is to have `json_encode()` and `json_decode()` raise warnings
> whenever a failure occurs, instead of requiring the developer to call
> `json_last_error()` each time.
>
> The functionality of `json_last_error()` and `json_last_error_msg()` are
> unaffected and they can still be used in exactly the same way they are today
>
> https://wiki.php.net/rfc/json_encode_decode_errors
>

I too think that JSON error handling can be a bit tedious at times,
but I certainly prefer it that way than having to suppress all
json_decode() calls.

Cheers,
Andrey.

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

Re: [PHP-DEV] [RFC] Raise warnings for json_encode() and json_decode() issues

[Nikita Popov]

On Fri, Jul 28, 2017 at 12:59 PM, Craig Duncan  wrote:

> Hi internals.
>
> As my initial thread about introducing warnings to the JSON functions was
> not immediately flooded with disagreement I took the liberty of creating an
> RFC for official discussion.
>
> The proposal is to have `json_encode()` and `json_decode()` raise warnings
> whenever a failure occurs, instead of requiring the developer to call
> `json_last_error()` each time.
>
> The functionality of `json_last_error()` and `json_last_error_msg()` are
> unaffected and they can still be used in exactly the same way they are
> today
>
> https://wiki.php.net/rfc/json_encode_decode_errors
>
> Thanks,
> Craig
>

Operations that are expected to fail should never generate warnings. We
should not design functions such that their correct use requires the use of
the error suppression operator.

I certainly agree that the current situation is not good and that the json
functions really ought to be throwing exceptions, but adding a warning now
is only going to make this worse.

Nikita

[PHP-DEV] [RFC] Raise warnings for json_encode() and json_decode() issues

[Craig Duncan]

Hi internals.

As my initial thread about introducing warnings to the JSON functions was
not immediately flooded with disagreement I took the liberty of creating an
RFC for official discussion.

The proposal is to have `json_encode()` and `json_decode()` raise warnings
whenever a failure occurs, instead of requiring the developer to call
`json_last_error()` each time.

The functionality of `json_last_error()` and `json_last_error_msg()` are
unaffected and they can still be used in exactly the same way they are today

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

Thanks,
Craig

Re: [PHP-DEV] json_encode() / json_decode() warnings

[Ryan Jentzsch]

I can't count how many times I've been bitten by this. From the infamous
fractal blog:

"Parts of PHP are practically designed to produce buggy code.
json_decode returns null for invalid input, even though null is also a
perfectly valid object for JSON to decode to—this function is completely
unreliable unless you also call json_last_error every time you use it."

Most functions in PHP return false as an indicator for an invalid call.
json_decode() returns null -- changing this to return false is also a
breaking change that may not survive a vote.

Because of the unreliability I don't use this function and always rely on
3rd party JSON libraries instead.

On Fri, Jul 28, 2017 at 12:59 AM, Niklas Keller  wrote:

> 2017-07-28 8:56 GMT+02:00 Giovanni Giacobbi :
>
> > On 27 July 2017 at 18:00, Craig Duncan  wrote:
> >
> >> On 27 July 2017 at 16:57, Niklas Keller  wrote:
> >>
> >> > It should rather just throw exceptions. Warnings do not really allow
> >> error
> >> > handling, they just allow error reporting.
> >> >
> >> >
> >> Agreed, but I can't see Exceptions passing the vote. Warnings can be
> >> silenced by those that don't care and converted to Exceptions by those
> >> that
> >> do
> >>
> >
> > Error management is a painful topic in PHP, expecially when considering
> to
> > the way fopen() behaves, where you *need* to use the "@" suppression if
> > you want it to behave the way you expect it to behave.
> >
> > About Exceptions you can easily build a framework around core functions,
> > for example this is in my core library for all projects:
> >
> > ```php
> > function safe_json_decode($json = null) {
> >   if ($json == "")
> > return null;
> >
> >   $retval = json_decode($json, true, 512, JSON_BIGINT_AS_STRING);
> >   if (json_last_error() != JSON_ERROR_NONE)
> > throw new JsonDecodeException(json_last_error_msg(),
> > json_last_error());
> >
> >   return $retval;
> > }
> > ```
> >
> > So yes, the behaviour of json_decode() might not be optimal, but it's
> fine
> > the way it is.
> >
>
> Yes, I know. There's https://github.com/DaveRandom/ExceptionalJSON.
>
> While the current API works, I'm not sure whether I'd say its fine.
>
> Regards, Niklas
>

Re: [PHP-DEV] json_encode() / json_decode() warnings

[Niklas Keller]

2017-07-28 8:56 GMT+02:00 Giovanni Giacobbi :

> On 27 July 2017 at 18:00, Craig Duncan  wrote:
>
>> On 27 July 2017 at 16:57, Niklas Keller  wrote:
>>
>> > It should rather just throw exceptions. Warnings do not really allow
>> error
>> > handling, they just allow error reporting.
>> >
>> >
>> Agreed, but I can't see Exceptions passing the vote. Warnings can be
>> silenced by those that don't care and converted to Exceptions by those
>> that
>> do
>>
>
> Error management is a painful topic in PHP, expecially when considering to
> the way fopen() behaves, where you *need* to use the "@" suppression if
> you want it to behave the way you expect it to behave.
>
> About Exceptions you can easily build a framework around core functions,
> for example this is in my core library for all projects:
>
> ```php
> function safe_json_decode($json = null) {
>   if ($json == "")
> return null;
>
>   $retval = json_decode($json, true, 512, JSON_BIGINT_AS_STRING);
>   if (json_last_error() != JSON_ERROR_NONE)
> throw new JsonDecodeException(json_last_error_msg(),
> json_last_error());
>
>   return $retval;
> }
> ```
>
> So yes, the behaviour of json_decode() might not be optimal, but it's fine
> the way it is.
>

Yes, I know. There's https://github.com/DaveRandom/ExceptionalJSON.

While the current API works, I'm not sure whether I'd say its fine.

Regards, Niklas

Re: [PHP-DEV] json_encode() / json_decode() warnings

[Giovanni Giacobbi]

On 27 July 2017 at 18:00, Craig Duncan  wrote:

> On 27 July 2017 at 16:57, Niklas Keller  wrote:
>
> > It should rather just throw exceptions. Warnings do not really allow
> error
> > handling, they just allow error reporting.
> >
> >
> Agreed, but I can't see Exceptions passing the vote. Warnings can be
> silenced by those that don't care and converted to Exceptions by those that
> do
>

Error management is a painful topic in PHP, expecially when considering to
the way fopen() behaves, where you *need* to use the "@" suppression if you
want it to behave the way you expect it to behave.

About Exceptions you can easily build a framework around core functions,
for example this is in my core library for all projects:

```php
function safe_json_decode($json = null) {
  if ($json == "")
return null;

  $retval = json_decode($json, true, 512, JSON_BIGINT_AS_STRING);
  if (json_last_error() != JSON_ERROR_NONE)
throw new JsonDecodeException(json_last_error_msg(), json_last_error());

  return $retval;
}
```

So yes, the behaviour of json_decode() might not be optimal, but it's fine
the way it is.

-- 
Giovanni Giacobbi

[PHP-DEV] [Request][Discussion] Introduce interfaces PDOInterface and PDOStatementInterface

[Andrew Nester]

Hello!

I’ve been working on request introduced here 
https://bugs.php.net/bug.php?id=74957  
related to implementing new PDOInterface and PDOStatementInterfaces.
At this point of time classes PDO and PDOStatement do not implement any 
interfaces that’s why code that uses PDO and PDOStatement are coupled and 
referred to concrete implementation , not interface.

It will help to add some custom classes and behavior to these classes and to 
decouple caller from details of PDO layer implementations.

At this point of time, the only way to add some custom classes and behavior is 
to approach this is by subclassing PDO and PDOStatement. 
You can use the PDO:: ATTR_STATEMENT_CLASS driver option to tell a PDO object 
which PDOStatement subclass to return from PDO::prepare().
But this is is not very straightforward and elegant (in terms of coding) way to 
do this.

But if PDO and PDOStatement implemented interfaces, it would be possible for 
the custom behaviour classes to implement those interfaces as well, making them 
interchangeable. 
No changes needed in callers of PDO/PDOStatement.

Here is my PR introducing this interface
https://github.com/php/php-src/pull/2657 


I would like to hear any feedback on it!
Thanks!