Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108395
MIME-Version: 1.0
References: <D5ACEB01-4E1E-407A-8441-D8C6E0D36CCA@gmail.com>
 <CADyq6s+SPJj_aGhg044XbW4KdRNYrV=bAxGX6ioMpihpg0E2SA@mail.gmail.com>
 <CAAKU0unkxUb7L60msbBe7Ch=v23=y3RaNjWWEaAQm79n7Ed63w@mail.gmail.com> <C3339DE6-2C9A-469E-8BA2-0B6F8CFE7055@gmail.com>
In-Reply-To: <C3339DE6-2C9A-469E-8BA2-0B6F8CFE7055@gmail.com>
Date: Tue, 4 Feb 2020 12:09:32 -0500
Message-ID: <CAPKYkKwpFEzzMOYZVuk+TTj=AT-rDLP+RN-6EjskR9H6BZ9JKw@mail.gmail.com>
To: Steven Wade <stevenwadejr@gmail.com>
Cc: Levi Morrison <levi.morrison@datadoghq.com>, Marco Pivetta <ocramius@gmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002ffc07059dc31bf3"
Subject: Re: [PHP-DEV] [RFC - discussion] __toArray()
From: chasepeeler@gmail.com (Chase Peeler)

--0000000000002ffc07059dc31bf3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=99re right, that=E2=80=99s my bad. I swore I tested print_r() w=
ith 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=E2=80=99ll update the RFC to remove the r=
eference
> 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 =3D array_map($callback,$arrayOrObject->toArray());
} else {
 $a =3D array_map($callback,$arrayOrObject);
}

becomes

$a =3D 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=E2=80=99s pretty magical already, so adding another magic method isn=
=E2=80=99t 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
>
>

--=20
Chase Peeler
chasepeeler@gmail.com

--0000000000002ffc07059dc31bf3--