Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107810
To: internals@lists.php.net
References: <461958fe-182e-59bf-9fdb-b110fd09e2b2@aimeos.com>
Message-ID: <b5111693-5f30-b493-8e1b-e0f6902f3a34@gmail.com>
Date: Sun, 17 Nov 2019 18:05:56 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <461958fe-182e-59bf-9fdb-b110fd09e2b2@aimeos.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Concept: "arrayable" pseudo type and \Arrayable
 interface
From: rowan.collins@gmail.com (Rowan Tommins)

On 17/11/2019 14:41, Aimeos | Norbert Sendetzky wrote:
> PHP frameworks would profit from support of an "arrayable" pseudo type
> hint that matches "array" and all objects that implements "Traversable",
> "ArrayAccess" and "Countable".

...

> It would be useful to implement an Arrayable interface too:
>
> interface Arrayable extends \Iterator, \Countable, \ArrayAccess
> {
>      public function toArray() : array;
> }


It feels like there are two alternative suggestions here. Not only do 
they use the same keyword to mean different things, but "convertible to 
array", and "usable as array" seem like distinct concepts to me.

For the "convertible to array" case, I think __toArray, or an interface 
specifying just that one method, would make more sense than combining it 
with the existing interfaces. I'm sceptical of that concept, though, 
because most objects could be converted to many different arrays in 
different circumstances, each of which should be given a different and 
descriptive name.

For the "usable as array" case, the big advantage would come if internal 
array_* functions could take such objects, but that requires a bit of 
thought on how each function should behave. There could also be some 
surprising behaviour passing infinite iterators, or objects where the 
output of ArrayAccess and iteration don't match up. It might make sense 
to have objects opt into an Arrayable interface, to make clear they're 
expecting to be used this way; but require no additional methods other 
than those required by Iterator (or Traversable), Countable, and 
ArrayAccess.

Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]