Fix Bug #77226: convert object which has invisible properties to array.

[twose]

all PHP versions and systems

script

$array = new class
{
    private $private = 1;
    protected $protected = 2;
    public $public = 3;
};
$array = (array)$array;
var_dump($array);

output

array(3) {
  ["0x00class@anonymous/path/to/array.php0x1099fd6330x00private"]=>
  int(1)
  ["0x00*0x00protected"]=>
  int(2)
  ["public"]=>
  int(3)
}

when we convert object which has invisible properties to array, it uses the zend_mangle_property_name result.
I think we can do what the json_encode does, skip protected and private members.

[nikic]

There's a lot of code relying on the current behavior, I doubt we can change it. It's possible to use get_object_vars() if you don't want to get mangled property names. It will return all properties that are visible from the current scope.

[twose]

There's a lot of code relying on the current behavior

...include output 0x00 in PHP script? I think this is terrible... Is this a feature?

[nikic]

@twose Object to array casts are a very fast and reliable way to access all the properties of an object. This is necessary for many libraries that do things like serialization, dumping, comparison, etc.

I definitely think that having this as a default behavior for array casts is bad, but it's not something we can simplify change at this point in time.

A good starting point may be to add a new function which provides the current functionality of object-to-array casts under a more explicit name and with less edge cases (e.g. ArrayObject is one of the big offenders, where you need to set a special flag to get normal array-to-object behavior). Libraries that need this functionality can then migrate to that function.

@Ocramius might be a good person to talk to about this.

[Ocramius]

This is indeed normal/expected. The \0 delimiters are even tested in the PHP integration tests.

[twose]

Thank you for your explanation, never thought that... 😧

[nikic]

@Ocramius What do you think about

A good starting point may be to add a new function which provides the current functionality of object-to-array casts under a more explicit name and with less edge cases (e.g. ArrayObject is one of the big offenders, where you need to set a special flag to get normal array-to-object behavior). Libraries that need this functionality can then migrate to that function.

[Ocramius]

I talked about it with @jpauli while at Web5 in 2013: ideally, I'd love to have an API like the one of zendframework/zend-hydrator, which allows populating state and extracting state. The problem with collisions in propert names inside an inheritance still exists, but I still believe that the \0 convention makes sense for now, as it is really really hard for userland code to manage to break that.

[Ocramius]

You could probably put such an API in:

• ReflectionObject#toArray(object $object)
• ReflectionClass#newInstanceFromState(array $state)

Bad idea? Absolutely, but it is not meant for OOP, and rather for serialisation purposes.

[jpauli]

What about __set_state() ? Cannot it help doing what you need ?

[Ocramius]

__set_state() is an API to be implemented on each class: I'm talking about something that allows me to instantiate anything at all, with pre-seeded state.

For tools like JMSSerializer, Doctrine ORM, zendframework/zend-di, zendframework/zend-servicemanager, php-di/php-di, ocramius/proxy-manager, phpunit and so on, this would be quite the massive speed-up.

For everyone else: not to be used, as it's gonna be something quite dangerous :-)

[jpauli]

Ok I see, we could add facilities to Reflection, that wouldn't be hard to program.
I guess we could write an RFC for PHP-next ?

[Ocramius]

Feasible, can probably help during the holidays. Should we take this offline, in private convo?

[jpauli]

Yes Ok you can fetch me by email or on IRC :-)