Re: [PHP-DEV] [RFC - discussion] __toArray()

This is only part of a thread. view whole thread
  108394
February 4, 2020 16:04 stevenwadejr@gmail.com (Steven Wade)
> 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.
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.
  108395
February 4, 2020 17:09 chasepeeler@gmail.com (Chase Peeler)
On Tue, Feb 4, 2020 at 11:04 AM Steven Wade <stevenwadejr@gmail.com> wrote:

> > > 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. > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Chase Peeler chasepeeler@gmail.com
  108396
February 4, 2020 17:13 stevenwadejr@gmail.com (Steven Wade)
> 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.
I couldn’t (and didn’t) have said it better myself. My motivation is really just to give developers more control over their code and allow them to have cleaner code.