[RFC - discussion] __toArray()

Am 04.02.20 um 14:43 schrieb Marco Pivetta:

I think we can't classify it as BC break, because no existing code
implements __toArray at the moment, and hence it will not fail when this
feature is introduced and code gets upgraded to newer versions.

It is a BC break because it changes the semantic of (array) $object: the
operation is no longer stable between two versions of the language.

It wouldn't be a BC breaking change if (array) $object works like
before when __toArray() isn't implemented by an object. As nobody should
have implemented __toArray() because it's a reserved name for magic
methods, we should be fine.

Linking (again) previous discussions:
https://externals.io/message/98539#98539

__toArray as a magic function call when (array) cast happen is a bad
idea: it is a BC break, and it removes one of the very few interactions
(with objects) that didn't cause any side-effects (
https://externals.io/message/98539#98545,
https://externals.io/message/98539#98567)

I think we can't classify it as BC break, because no existing code
implements __toArray at the moment, and hence it will not fail when this
feature is introduced and code gets upgraded to newer versions.

It is a BC break because it changes the semantic of (array) $object: the
operation is no longer stable between two versions of the language.

Code relying on (array) behaviour (stable) requires additional
reflection wrappers to check if $object is not implementing
__toArray, and then the operation can be safely used (or an exception is
to be thrown).

You can most certainly make a new operation, such as (toArray) $object:
the cast operator is new and isn't changing any existing behaviour.

I believe the definition of BC break is "can an existing code-base run on
the new PHP version without changes" and here the answer is yes, since
__toArray fn's are not used by any existing code bases.

What you refer to is, can existing code work with new code using this
feature, and then the answer is indeed no. But the same was true for
example for typed properties, which also requires additional handling in
most meta programming libraries, and many other new features that existing
libraries needed to adapt to: namespaces, scalar type hints, return types,
...

Sorry if it's been said in the discussion so far, but I do not see why
print_r should convert anything to an array. It accepts multiple
kinds of types including strings, numbers, and so on, and I think
adding this behavior to print_r is a different thing than wanting a
standard way for objects to be converted into arrays.

You’re right, that’s my bad. I swore I tested print_r() with a class and
__toString() and it cast it, but I just ran it again and it just outputs
the object. The goal would be to have __toArray() behave on arrays like
__toString() does on strings. I’ll update the RFC to remove the reference
to print_r(). Thanks!

And on that note, what is the motivation for wanting a magic method
for converting an object into an array? Why not make it an explicit
operation? I do not see the point of the magic here, except maybe
for adding it to ArrayObject or something to allow it to work with
the array_* functions that work without references, in which case I
think we think this RFC is the wrong approach as it is inadequate for
that purpose.

I think the motivation is exactly what you said. Allowing developers more
control over how the object is treated when casted to an array - which
would include when it is passed into an array_* function.

Here is a use-case:
if(is_object($arrayOrObject)){
$a = array_map($callback,$arrayOrObject->toArray());
} else {
$a = array_map($callback,$arrayOrObject);
}

becomes

$a = array_map($callback,$arrayOrObject);

I'm not making an argument one way or the other for whether the above is
justification, but, it does at least allow the above simplification of code.

PHP’s pretty magical already, so adding another magic method isn’t out of
the question and would keep things inline with how some things are done
already. The idea for having magical casting is to make it simpler in the
user land for general array behavior when reading or looping.

--
Chase Peeler
chasepeeler@gmail.com

3. The weak point of this proposal is the by reference handling for sort et al. Counterpoint: if you pass a variable to preg_match, then matches gets converted from anything to array, so i believe by reference casting should change the original value (https://3v4l.org/XUJ5m https://3v4l.org/XUJ5m). This is weird, but consistent.

The proposal states that “array functions that operate on an array by reference such as sort or shuffle will not work on an object implementing __toArray() under this proposal”, and IMO that is consistent with other magical casting behaviors and I wouldn’t expect a class implementing __toArray() to be able to be written or referenced like a traditional array.

Passing an object with toString by reference will change the original variable: https://3v4l.org/77lov https://3v4l.org/77lov
Ah, I think I see what you mean. PHP’s making a copy of the string variable once it’s cast, so it’s no longer referencing the original object that implemented the __toString() method. I imagined the __toArray() would function the same. Once the cast is called on the object, it’s a new array variable and can be acted upon as such. What I was trying to get at was that the magic method does not give the ability to write to the original object. If that’s not clear then I need to update the RFC.