Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107812
Message-ID: <1BF6C8EC-6DF1-4481-94B2-3A6E7D1312BE@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_8E716A27-8F02-4D71-864F-4738263F1893"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 17 Nov 2019 18:01:46 -0500
In-Reply-To: <7b527bbb-47e3-9b24-8766-c15e6334c78a@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>
Subject: Re: [PHP-DEV] Concept: "arrayable" pseudo type and \Arrayable
 interface
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_8E716A27-8F02-4D71-864F-4738263F1893
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On Nov 17, 2019, at 2:27 PM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
> Well, pretty much any method that returns array *could* be called "to =
array", but not many would be good candidates for such a generic name. =
You might return an array structure to be incorporated into a JSON =
response, or to be passed to a template renderer, or to map to database =
columns, etc.
>=20
> The only case I can think of where a generic "toArray" method would =
make sense is if you're creating a general-purpose "collection" or =
"list" object, in which case you're probably better off directly =
implementing methods like map and sort, rather than encouraging users to =
convert it back to a plain array. It doesn't seem like a common enough =
use case to need a new language feature, when it's simple enough to =
write "$foo->toArray()" without anything new.

I have been pondering that objection ever since Steven Wade proposed =
__toArray() on the list a few months back. =20

In part I agree with the sentiment, and in part I feel that perfection =
is being the enemy of the good here.  But as I had no strong argument =
for how it could be done better I did not say anything on the matter.

Consider this: __toArray() is hardly a rare case where a short name can =
be applied in multiple contexts.  We have infinite contexts where we =
need to name methods for one context that might conflict with others, =
and so I have been agonizing for years over how to deal with this =
conundrum without resorting to really long method names.=20

(As an aside, I think long method names result in harder to comprehend =
code, and as I have never seen a set of conventions that results in =
multiple programmers (almost) always choosing the same long names for =
the same use-cases I prefer our standards to suggest shorter names so =
that we can maintain more consistence across programmers.)

Recently I have been experimenting with using namespaces instead of long =
method names, and I think using them can result in the best of both =
worlds and resolve your concern.  Consider the following classes, each =
of which could have their own __toArray() method specific to their =
use-case:
\Widgets\Widget
\Widgets\JSON\Widget
\Widgets\Mustache\Widget
\Widgets\DbColumns\Widget
With the above you can "have your cake and eat it too."  Your namespace =
can specify the exact context for your __toArray() and thus developers =
who want to use that architecture can get the benefits of a __toArray() =
magic method.

#jmtcw

-Mike=

--Apple-Mail=_8E716A27-8F02-4D71-864F-4738263F1893--