Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107816
Message-ID: <EA2A1973-9C65-40A6-826D-32D48354962E@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_142ADE1C-C0CC-46CA-83DF-3A03D6694901"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 17 Nov 2019 19:18:40 -0500
In-Reply-To: <ce1d79e9-7e42-cd5e-360a-3b6b86064f55@gmail.com>
Cc: Rowan Tommins <rowan.collins@gmail.com>
To: PHP Internals <internals@lists.php.net>
References: <461958fe-182e-59bf-9fdb-b110fd09e2b2@aimeos.com>
 <b5111693-5f30-b493-8e1b-e0f6902f3a34@gmail.com>
 <08de5448-3c5a-ad32-555e-b8f9579c1337@aimeos.com>
 <7b527bbb-47e3-9b24-8766-c15e6334c78a@gmail.com>
 <1BF6C8EC-6DF1-4481-94B2-3A6E7D1312BE@newclarity.net>
 <ce1d79e9-7e42-cd5e-360a-3b6b86064f55@gmail.com>
Subject: Re: [PHP-DEV] Concept: "arrayable" pseudo type and \Arrayable
 interface
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_142ADE1C-C0CC-46CA-83DF-3A03D6694901
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Nov 17, 2019, at 6:51 PM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> I'm not sure avoiding the name "toArray" necessarily leads to "really =
long method names" - even with extremely specific distinctions, you =
don't need to call the method "toJsonArrayForVersion5OfTheApi", just =
"toV5Json" or "getV5Array" or "formatForJsonV5".

I now realize that my commenting on my experience in reviewing legacy =
code =E2=80=94 where long names are frequently used, regardless of the =
fact they are not required =E2=80=94 caused you to focus on the long =
naming comment aside and not on the primary ask for consistency. =20

Even if short, a code base littered with method names like toV5Json() or =
getV5Array() or formatForJsonV5() is still inconsistent.

> The important thing is that the method name is now communicating its =
*purpose*, whereas "toArray" communicates only its return type, and a =
hugely flexible return type at that.

What I was suggesting instead, which obviously was not clear, is that =
you communicate the *purpose* with the namespace and by doing so allows =
for the capability of casting to array be added.  Otherwise the perfect =
is the enemy of the good.

> I'm not clear what these objects represent. If I have a Widget object =
passed out from some business logic,

Similarly it is not clear to me was toV5Json() or getV5Array() or =
formatForJsonV5() mean.

However if V5 somehow has meaning then your namespaces class could just =
as easily be named if that is what you want:

\Widgets\ToV5Json\Widget

> how do I make use of these other classes? Would I have to call =
"(array)(new \Widgets\Mustache\Widget($myWidget))", as sugar for "(new =
\Widgets\Mustache\Widget($myWidget))->__toArray()"?

Maybe we code differently, but I would never write a full namespace in =
code like that. I would have one of the following at the top of my PHP =
file:

use \Widgets\Mustache\Widget
use \Widgets\Mustache\Widget AS MustacheWidget=20

That would result in the following as one of =E2=80=94 a you say =E2=80=94=
 sugar for (new \Widgets\Mustache\Widget($myWidget))->__toArray():

(array)(new Widget($myWidget))
(array)(new MustacheWidget($myWidget))

However I doubt I would ever instantiate and then cast the object in the =
same line of code. Instead the value of array casting =E2=80=94 to me =
=E2=80=94 is in its polymorphic nature where I can have a "generic" =
method that can just cast to an array and instead of having to know if =
the developer used toV5Json() or getV5Array() or formatForJsonV5().

> If so, I don't really see the benefit of the magic method over just =
standardising a method name, like "interface MustacheFormatter { public =
function getData(): array; }"

Backward compatibility is the benefit.  If we standardize one any name =
then we can break existing code. Adding a magic method cannot break =
existing code unless that code violated the reserved nature of double =
underscore methods.=20

Or are you proposing we start adding __*() methods that are not actually =
magic?

> Which is basically my objection to __toArray() - I can't think of many =
situations where writing (array)$foo saves or gains you anything over =
writing $foo->asArray() or $foo->somethingMoreSpecific()

But I and others can think of situations where it would help.=20

Because asArray() and somethingMoreSpecific() are neither a standard you =
don't get polymorphism with different named methods.=20

And any new standard non-magic method we add has the potential to break =
BC.  And is unlike anything else in PHP I can think of.

OTOH, I have a hard time thinking of a scenario where __toArray() would =
actually cause a problem for someone like you who cannot think of a =
benefit.  Can you present a use-case how it would cause you a tangible =
problem that could not be resolved with namespaces or by just creating =
your own somethingMoreSpecific() method and ignoring __toArray()?

-Mike=

--Apple-Mail=_142ADE1C-C0CC-46CA-83DF-3A03D6694901--