Re: [RFC] Iterable
| From: | Jeremy Mikola | Date: | Thu, 30 Jun 2016 20:01:38 +0000 |
| Subject: | Re: [RFC] Iterable | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-94340@lists.php.net to get a copy of this message | ||
On Sat, Jun 18, 2016 at 11:34 AM, Aaron Piotrowski <aaron@trowski.com>
wrote:
>
> I plan on bringing the iterable RFC (https://wiki.php.net/rfc/iterable)
> to a vote in about a week, does anyone have any further feedback on this
> proposal?
>
Was there any discussion about a special allowance being made for stdClass?
I've noted the is_iterable(new stdClass) example and ensuing "Object
Iteration" section:
PHP allows any object to be used with foreach. However, iterable does not
> accept any object, only those implementing Traversable. Values accepted
> by iterable should be designed for iteration, not any set of values (such
> as the public properties of an object or a string).
>
I'm on the fence if that second sentence applies to stdClass. Based on how
users typically end up with stdClass instances (e.g. casting arrays to an
object, json_decode()), I tend to think of them as logically equivalent to
associative arrays. To that end, I'd consider stdClass to be as "designed
for iteration" as any associative array -- if we can even say a stdClass
was designed at all :)
As-is, the RFC requires users to either cast stdClass instances to an array
or decorate them with an Iterator (e.g. ArrayObject). I find this a bit
irksome, but it's certainly easy to work around.
That said, I realize that voting is in progress and it's not my intention
to interrupt anything. I just wanted to relay a viewpoint that might not
have come up.
--
jeremy mikola