Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105692
Message-ID: <898DDEB6-4CC3-44F8-8583-BC3AE22C6928@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_F0741627-01C7-403C-8F0D-F875EB6DFBE3"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Mon, 13 May 2019 14:55:07 -0400
In-Reply-To: <CALKiJKp9J4p-5C6cbZ0kRtO9cT34Nh93LgkcM-yQ137ZOGJ37g@mail.gmail.com>
Cc: Internals <internals@lists.php.net>
To: Rowan Collins <rowan.collins@gmail.com>
References: <FB70FDD7-53AA-4DB4-B747-6E109BE52C2E@gmail.com>
 <1946899E-7EFC-4206-B26D-CD44838315A3@gmail.com>
 <CALKiJKp9J4p-5C6cbZ0kRtO9cT34Nh93LgkcM-yQ137ZOGJ37g@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: Proposal for a RFC
From: stevenwadejr@gmail.com (Steven Wade)

--Apple-Mail=_F0741627-01C7-403C-8F0D-F875EB6DFBE3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> I'm personally unconvinced of the value of this, and would probably =
propose
> it was blocked by coding standards in my team if it was added, because =
its
> meaning is so ambiguous.

That's perfectly reasonable. Do you also block use of casting to a =
string with (string) $foo as well? I ask because this proposal is simply =
on par with the idea behind string casting for objects.=20

I don't expect that everyone would use custom array casting via =
__toArray(), but for those that would like to have that control and ease =
of use, it'd be valuable for them.

> I actually see quite a lot of classes with normal methods called =
things
> like "toArray", and my comment is always "to *what* array?" Most =
objects do
> not have a single "natural"/"canonical" array representation

I think the same could be said about "__toString()". But with that, some =
classes can be boiled down to a single representation, such as the =
Ramsey\Uuid <https://github.com/ramsey/uuid/> package. The same is with =
arrays. You can have a single entity such as person to where its array =
representation can be first name, last name, age, race, gender, email, =
etc..., or you can have a collection of items, to where in that =
representation as an array, you have control over what information is =
returned and what isn't.

> As a thought experiment, imagine a similar method which allowed you to
> overload (object)$foo. Although (array)$foo tells you slightly more =
than
> that, I'm not convinced it tells you enough that you're not just =
hiding
> meaning behind cute syntax.

I'm confused by example, as there's no real need to overload casting to =
an object as a class is already an object. Whereas, a class is not =
already an array. It's not about "cute syntax", it's honestly about =
providing a simple clutter free helper for developers to take control =
over how their classes are transformed to array representations.

> JsonSerializable actually suffers from similar problems, and is IMO =
useful
> only because it's automatically recursive. I presume the proposed =
mechanism
> would not be, i.e. return [$foo] would not be interpreted as return
> [(array)$foo].

You bring up a good point. Could you for a moment pretend like you're =
behind this proposal and expand upon this question? If PHP were to have =
a __toArray() method, would you see it as being recursive? In your =
opinion, how should/would it react?

I know not everyone will want or use this feature, but for those who =
would, it'd be a great addition IMO. So my goal of this initial thread =
was to see, "what if we had this feature, what would we want it to do?", =
and go from there.

--
Steven Wade
stevenwadejr@gmail.com




--Apple-Mail=_F0741627-01C7-403C-8F0D-F875EB6DFBE3--