Everything

php

Home » Project » Newsgroups » php.internals » [RFC][VOTE] Improve array to string conversion »

[RFC][VOTE] Improve array to string conversion

php.internals

François Laupretre

11 years ago

Hi,

Starting the vote for https://wiki.php.net/rfc/array-to-string.

Please note that, while the initial RFC proposed both options of either
fully supporting the feature, or disabling it, the voting choices are now :

- either definitely disabling array to string conversion,
- or keep current behavior as-is.

Vote ends March 6, 00:00 (UTC).

Regards

François

Unnamed Person

11 years ago

I think this is a huge bc break that will affect many applications. For example:

// test.php
error_reporting(E_ALL & ~E_NOTICE);
echo $_GET['value'];

curl http://.../test.php?value=foo // ok
curl http://.../test.php?value[0]=foo&value[1]=bar // application continues with E_NOTICE
curl http://.../test.php?value[0]=foo&value[1]=bar // application stops with E_RECOVERABLE_ERROR


François Laupretre wrote on 23.02.2015 17:06:

Leigh

11 years ago

On 24 February 2015 at 19:23, Thomas Bley <mails@thomasbley.de> wrote:

> I think this is a huge bc break that will affect many applications. For example:
>
> // test.php
> error_reporting(E_ALL & ~E_NOTICE);
> echo $_GET['value'];
>
> curl http://.../test.php?value=foo // ok
> curl http://.../test.php?value[0]=foo&value[1]=bar // application continues with E_NOTICE
> curl http://.../test.php?value[0]=foo&value[1]=bar // application stops with E_RECOVERABLE_ERROR

While this is true I think in this particular case if you're doing
array to string conversion somewhere, your application probably isn't
doing what you think it's doing. I think it's better to prevent
unhelpful and unexpected behaviour than to carry on silently.

Unnamed Person

11 years ago

There are many cases where applications are not transactions safe, e.g. calling multiple external interfaces via soap, json, xml, etc.
If the application suddenly stops between two external calls - where it could not stop before - you get unexpected behavior.


Leigh wrote on 24.02.2015 20:29:

Laruence

11 years ago

Hey:

On Tue, Feb 24, 2015 at 12:06 AM, François Laupretre <francois@php.net> wrote:

> Hi,
>
> Starting the vote for https://wiki.php.net/rfc/array-to-string.
>
> Please note that, while the initial RFC proposed both options of either
> fully supporting the feature, or disabling it, the voting choices are now :
>
> - either definitely disabling array to string conversion,
> - or keep current behavior as-is.
>
> Vote ends March 6, 00:00 (UTC).

replace E_NOTICE with E_RECOVERABLE_ERROR??

it's a huge BC break.....

I vote -1 on this.

thanks

>
> Regards
>
> François
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

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

Pascal MARTIN

11 years ago

Le 23/02/2015 17:06, François Laupretre a écrit :

> Starting the vote for https://wiki.php.net/rfc/array-to-string.

Hi,

We talked about this with other people at AFUP and a great majority of
us agrees that the current behavior of array to strings conversions is
not quite useful -- and, for several of us, when we started getting
notices with PHP 5.4, it actually showed us there were bugs in our
applications.

So, we are +1 on this.

Basically, even if notices are already bringing some useful information,
we feel being more "strict" and "explicit" than that might help, here.

As a sidenote, an idea that was suggested a few times was that adding
some kind of __toString() method on arrays could be useful in some cases
-- but this goes a lot farther than this RFC...

Thanks,

--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/

Patrick ALLAERT

11 years ago

Le jeu. 5 mars 2015 à 23:20, Pascal Martin, AFUP <mailing@pascal-martin.fr>
a écrit :

> Le 23/02/2015 17:06, François Laupretre a écrit :
> > Starting the vote for https://wiki.php.net/rfc/array-to-string.
>
> Hi,
>
> We talked about this with other people at AFUP and a great majority of
> us agrees that the current behavior of array to strings conversions is
> not quite useful

Nor are all the following operations:

$useOfUnexistingVariableIsOkToContinueExecution = $variableNotSet;

$obj = new stdClass();
$useOfUnexistingPropertyIsOkToContinueExecution = $obj->notFound;

$computingWithObjectIsOkToContinueExecution = 42 + new stdClass();

$array = array(42);
$useOfUnexistingOffsetIsOkToContinueExecution = $array[42];

$int = 42;
$usingANumberAsAnArrayIsFineNoNotice = $int["foo"];

$null = NULL;
$usingANonObjectAsAnObjectIsOkToContinueExecution = $null->notAnObject;

$resource = fopen("/etc/hosts", "r");
$resourceToStringConversionIsOkToContinueExecution = (string) $resource;

Running the above would produce:

PHP Notice:  Undefined variable: variableNotSet in - on line 2

Notice: Undefined variable: variableNotSet in - on line 2
PHP Notice:  Undefined property: stdClass::$notFound in - on line 5

Notice: Undefined property: stdClass::$notFound in - on line 5
PHP Notice:  Object of class stdClass could not be converted to int in - on
line 7

Notice: Object of class stdClass could not be converted to int in - on line
7
PHP Notice:  Undefined offset: 42 in - on line 10

Notice: Undefined offset: 42 in - on line 10
PHP Notice:  Trying to get property of non-object in - on line 16

Notice: Trying to get property of non-object in - on line 16

-- and, for several of us, when we started getting

> notices with PHP 5.4, it actually showed us there were bugs in our
> applications.
>

Which confirms that turning notices 'On' would allow anyone to fix code
that may seems suspect.

> So, we are +1 on this.
>
> Basically, even if notices are already bringing some useful information,
> we feel being more "strict" and "explicit" than that might help, here.
>

Why suddenly changing that specific notice, without deprecation, to one
that stop the execution and without "opt-in" for it? (and according to the
patch, only in some "array to string conversion", not all?)

I'm about to post another suggestion in a fork of this discussion which
might fit anyone, stay tuned!

Cheers,
Patrick

Patrick ALLAERT

11 years ago

Le lun. 23 févr. 2015 à 17:06, François Laupretre <francois@php.net> a
écrit :

> Hi,
>
> Starting the vote for https://wiki.php.net/rfc/array-to-string.
>
> Please note that, while the initial RFC proposed both options of either
> fully supporting the feature, or disabling it, the voting choices are now :
>
> - either definitely disabling array to string conversion,
> - or keep current behavior as-is.
>
> Vote ends March 6, 00:00 (UTC).
>
> Regards
>
> François
>

As said in the original thread [1], I'm not in favor of breaking the
execution in the case of "Array to string" conversion with an
E_RECOVERABLE_ERROR with no "opt-in" choice for that (which implies an
important BC break).

However, maybe there is a better option for those that want to be 'more
"strict" and "explicit"' (quoting Pascal Martin [2]).

Having the option to bail out at any kind of errors (E_NOTICE,
E_WARNING,...) might fit that as well.
gcc has a similar switch:
"-pedantic-errors:   Like -Wpedantic, except that errors are produced
rather than warnings."

This could be easily developed thanks to a configuration switch (off by
default) or an "error_reporting"-like bit field instructing on which error
level to bail out additionally.

By doing so, we would let people opt-in for that kind of behaviour.

Thoughts?

[1] http://marc.info/?t=142470775700006
[2] http://marc.info/?l=php-internals&m=142559407125491