Add __toArray() method to objects that would be called on cast to array

On Wed, Mar 15, 2017 at 11:49 AM, Benoît Burnichon bburnichon@gmail.com
wrote:

Hi all,

Looking at code of PHPUnit, I stumbled upon an inconsistent array
conversion:

---

/**

• @param ArrayAccess|array $other
  */
  function evaluate($other)
  {
  // type cast $other as an array to allow
  //support in standard array functions.
  if ($other instanceof ArrayAccess) {
  $data = (array) $data;
  }

$patched = array_replace_recursive($other, $this->subset);

// ...
}

This would work only for ArrayAccess implementations extending
ArrayObject as shown by https://3v4l.org/ti4aY

Looking at the manual
http://php.net/manual/en/language.types.array.php#
language.types.array.casting
,
it seems ArrayObject class does not comply to array casting because
integer public properties could also be retrieved. Some tests showed that
regular class always have string keys even when a $key = 0; $this->{$key} = 'avalue'; is called. In this case, var_export((array)$object); returns
array('0' => 'avalue') (Notice the quote around key 0 -
https://3v4l.org/6QW70)

What do you think of adding an optional __toArray() method to classes
which would default to current behavior but would allow specifying
behavior. The way of internal __toString() method and could explain
inconsistency of the ArrayObject class?

I like the idea kind of, but would this remove the ability to cast to array
all classes not implementing __toArray, as is the case with __toString?
This would be a HUGE BC if so:

$ php -r 'class Foo {public $foo = "foobar";} var_dump((array) (new Foo));'
array(1) {
["foo"]=>
string(6) "foobar"
}
$ php -r 'class Foo {public $foo = "foobar";} var_dump((string) (new Foo));'
PHP Recoverable fatal error: Object of class Foo could not be converted to
string in Command line code on line 1
$ php -v
PHP 7.1.2 (cli) (built: Feb 27 2017 00:02:44) ( ZTS )

Regards,

Benoît Burnichon

Hi all,

Looking at code of PHPUnit, I stumbled upon an inconsistent array
conversion:

---

/**

• @param ArrayAccess|array $other
  */
  function evaluate($other)
  {
  // type cast $other as an array to allow
  //support in standard array functions.
  if ($other instanceof ArrayAccess) {
  $data = (array) $data;
  }

$patched = array_replace_recursive($other, $this->subset);

// ...
}

This would work only for ArrayAccess implementations extending
ArrayObject as shown by https://3v4l.org/ti4aY

Looking at the manual
http://php.net/manual/en/language.types.array.php#language.types.array.casting
,
it seems ArrayObject class does not comply to array casting because
integer public properties could also be retrieved. Some tests showed that
regular class always have string keys even when a $key = 0; $this->{$key} = 'avalue'; is called. In this case, var_export((array)$object); returns
array('0' => 'avalue') (Notice the quote around key 0 -
https://3v4l.org/6QW70)

What do you think of adding an optional __toArray() method to classes
which would default to current behavior but would allow specifying
behavior. The way of internal __toString() method and could explain
inconsistency of the ArrayObject class?

Regards,

Benoît Burnichon

Wouldn't it also be possible to add a Arrayable interface with a
totally normal toArray method? This would avoid littering code bases
even more with feature detection code like
method_exists($x, '__toString').

There would be nothing special to do here, other than implementing that
interface for all core classes for which it makes sense.

The only question that remains (regardless of the strategy) would be: is
it iterable? I guess the answer "yes" is obvious here. Hence,
Arrayable would need to extend at least Traversable.

--
Richard "Fleshgrinder" Fussenegger

This is a BC break due to the fact that the (array) cast is used to
extract property information from private properties in library code.

Hi all,

Looking at code of PHPUnit, I stumbled upon an inconsistent array
conversion:

---

/**

• @param ArrayAccess|array $other
  */
  function evaluate($other)
  {
  // type cast $other as an array to allow
  //support in standard array functions.
  if ($other instanceof ArrayAccess) {
  $data = (array) $data;
  }

$patched = array_replace_recursive($other, $this->subset);

// ...
}

This would work only for ArrayAccess implementations extending
ArrayObject as shown by https://3v4l.org/ti4aY

Looking at the manual
http://php.net/manual/en/language.types.array.php#
language.types.array.casting
,
it seems ArrayObject class does not comply to array casting because
integer public properties could also be retrieved. Some tests showed that
regular class always have string keys even when a $key = 0; $this->{$key} = 'avalue'; is called. In this case, var_export((array)$object); returns
array('0' => 'avalue') (Notice the quote around key 0 -
https://3v4l.org/6QW70)

What do you think of adding an optional __toArray() method to classes
which would default to current behavior but would allow specifying
behavior. The way of internal __toString() method and could explain
inconsistency of the ArrayObject class?

Regards,

Benoît Burnichon

Hi Benoît,

Benoît Burnichon wrote:

Looking at the manual
http://php.net/manual/en/language.types.array.php#language.types.array.casting
,
it seems ArrayObject class does not comply to array casting because
integer public properties could also be retrieved. Some tests showed that
regular class always have string keys even when a $key = 0; $this->{$key} = 'avalue'; is called. In this case, var_export((array)$object); returns
array('0' => 'avalue') (Notice the quote around key 0 -
https://3v4l.org/6QW70)

I'm not sure what specifically you see to be the problem, but I think it
might be worth directing you to my RFC which relates to this:

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

--
Andrea Faulds
https://ajf.me/

As just told: existing code hinting against generic object breaks. This
is a change in semantics in an existing operator. It is just sane to
consider it a BC break, since the operator cannot be relied upon for a
certain family of problems: invent a new operator.

That's basically the path to follow anytime something could be overloaded,
but shouldn't due to BC constraints.

What changes is the interface of the (array) operator.

I understand what you mean, I just disagree that it constitutes a BC break
in the sense that no existing code would break/misbehave by simply updating
to a PHP version including the feature.

That's just the only sane criteria by which to label changes as BC breaks,
because if we don't stick to that, there'd be an argument to be made that
literally every change is. And that would mean the term loses its meaning
and becomes useless.

Cheers,
Andrey.

Since some folks keep banging on "it's not a BC break", I propose a
challenge in fixing this particular BC break example (reads: find a
different way to make it work, and no warnings/notices allowed):

I made a very simplistic example of where __toArray will break existing
API that currently literally accepts any kind of object:
https://3v4l.org/Tj0GH

For reference, here's the code copy:

<?php

class Foo
{
public $bar;
public $baz;
public $taz;
}

// please note that this API has a signature of object $object - any
object allowed.
function unsetProperties($object) {
// we ignore inheritance and private properties for simplicity
return array_diff(
array_map(
function (\ReflectionProperty $p) : string {
return $p->getName();
},
(new ReflectionClass($object))->getProperties()
),
array_keys((array) $object)
);
}

var_dump(unsetProperties(new Foo));

$foo = new Foo;

unset($foo->baz);

var_dump(unsetProperties($foo));

There are dozens of simpler examples that break (typically, data-mapper
layers): I picked this particular one because there is no other way to
detect unset properties without causing side-effects.

If __toArray is implemented on an object, the API defined above will
either report all properties to be unset, or in general produce unreliable
results.

The current API specification of the (array) operator is as following:

• for every SET property produce an array value, with the key being:
  • "\0" . $className . "\0" . $propertyName for private properties
  • "\0*\0" . $propertyName for protected properties
  • $propertyName for public properties
  • $propertyName for dynamically defined properties

This is a VERY SPECIFIC behavior that the operator currently
guarantees. Break that, and you can go on github hunting for (array) cast
usages.

The behavior was frozen in the current suite in https://github.com/php/php-
src/blob/8015daeddb7bb4951c808fa253b97753787fb0ea/tests/classes/
array_conversion_keys.phpt (although, now that I notice, doesn't cover
dynamically defined properties - should add that).

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/