[VOTE] Making stdClass iterable

php.internals

Craig Duncan (PHP)

7 years ago
Hi all, Following the discussion it's now time to vote on whether we make the stdClass iterable or not. https://wiki.php.net/rfc/iterable-stdclass Note that while there is an implementation available, the vote is only on whether stdClass should fulfil the Traversable interface or not. Nikita had some ideas on a different implementation that I'll revisit if the vote passes. Voting will end in two weeks on 2019-02-18 Thanks to everybody that shared their opinion and raised concerns during the discussion. Craig

Côme Chilliet

7 years ago
Hello, What is the usecase for this? The RFC does not explain what it would be useful for. json_decode already provides an option for getting arrays instead of objects. All in all the RFC does not provide enough information. As I understand it if stdClass is Traversable then all objects are, no? Côme

Michał Brzuchalski

7 years ago
wt., 5 lut 2019 o 10:24 Côme Chilliet <come@opensides.be> napisał(a):
> Hello, > > What is the usecase for this? > > The RFC does not explain what it would be useful for. > json_decode already provides an option for getting arrays instead of > objects. > > All in all the RFC does not provide enough information. As I understand it > if stdClass is Traversable then all objects are, no? > >
stdClass is not a super class so none of the objects in core neither userland are derived from stdClass
> Côme > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- regards / pozdrawiam, -- Michał Brzuchalski about.me/brzuchal brzuchalski.com

Levi Morrison

7 years ago
On Mon, Feb 4, 2019 at 11:58 AM Craig Duncan <php@duncanc.co.uk> wrote:
> > Hi all, > > Following the discussion it's now time to vote on whether we make the > stdClass iterable or not. > https://wiki.php.net/rfc/iterable-stdclass > > Note that while there is an implementation available, the vote is only on > whether stdClass should fulfil the Traversable interface or not. > Nikita had some ideas on a different implementation that I'll revisit if > the vote passes. > > Voting will end in two weeks on 2019-02-18 > > Thanks to everybody that shared their opinion and raised concerns during > the discussion. > > Craig
I just wanted to pipe in to suggest an alternative approach to accomplish some of the same goals: an external PropertyIterator. - It could allow us to refine which property visibilities we care to iterate over. For instance, if we are in a protected or private context we may want to still only iterate over public properties. - I think that with typed properties we will see more data-only classes which would benefit from an external PropertyIterator. Of course, that still means `stdClass` isn't automatically `iterable`, but if you want it to be then you can pass in a PropertyIterator instead.

Craig Duncan (PHP)

7 years ago
On Tue, 5 Feb 2019 at 16:39, Levi Morrison <levim@php.net> wrote:
> I just wanted to pipe in to suggest an alternative approach to > accomplish some of the same goals: an external PropertyIterator. >
I believe Nikita suggested something similar, and while it would certainly be useful it doesn't accomplish the same goals as this proposal. The goal of this proposal is to make the language more consistent and less surprising. The *iterable* type accepts a plain array, but not an object that is used to represent a plain array, that's surprising to me. *stdClass* is "promoted" as part of the language, it's use is not advised against anywhere in the manual, and it's the default response format for *json_decode()* To me, this class is presented as a first class citizen, but it works like a second class one. As it looks like my first approach to resolving this inconsistency is likely to fail the vote, I'm considering a second approach now to update the docs and "officially" deprecate/discourage usage of *stdClass*

Rowan Collins

7 years ago
On Tue, 5 Feb 2019 at 17:25, Craig Duncan <php@duncanc.co.uk> wrote:
> The *iterable* type accepts a plain array, but not an object that is used > to represent a plain array, that's surprising to me. >
I think this notion of stdClass as "an object used to represent a plain array" is a peculiar one. The only reason I can think of for using stdClass is to specifically *not* be like an array in some way. As I mentioned in the discussion thread, the closer comparison would be to an anonymous class: $foo = new stdClass; and $foo = new class {}; both produce objects with no behaviour, no pre-defined methods, and the ability to define properties dynamically. On that definition, there's no surprise at all: it's an object that has no defined behaviour, so is not defined as having the "iterable" behaviour.
> To me, this class is presented as a first class citizen, but it works like > a second class one. >
While I agree that it's an anomaly in many ways, I think the fact that it's not marked iterable is a peculiar detail to get stuck on. Regards,
-- Rowan Collins [IMSoP]

Chase Peeler

7 years ago
On Tue, Feb 5, 2019 at 1:46 PM Rowan Collins <rowan.collins@gmail.com> wrote:
> On Tue, 5 Feb 2019 at 17:25, Craig Duncan <php@duncanc.co.uk> wrote: > > > The *iterable* type accepts a plain array, but not an object that is used > > to represent a plain array, that's surprising to me. > > > > > I think this notion of stdClass as "an object used to represent a plain > array" is a peculiar one. The only reason I can think of for using stdClass > is to specifically *not* be like an array in some way. > > As I mentioned in the discussion thread, the closer comparison would be to > an anonymous class: $foo = new stdClass; and $foo = new class {}; both > produce objects with no behaviour, no pre-defined methods, and the ability > to define properties dynamically. > > In other words, while stdClass CAN represent a plain array in cases where
you've casted an array to an object: $c = (object)$array; there is nothing that says ALL instances of stdClass represent a plain array. At the point that the instance isn't representing an array, it's no more iterable than any other class that has properties. You can still iterate the public properties of a class though, even when is_iterable returns false.
> On that definition, there's no surprise at all: it's an object that has no > defined behaviour, so is not defined as having the "iterable" behaviour. > > > > > To me, this class is presented as a first class citizen, but it works > like > > a second class one. > > > > > While I agree that it's an anomaly in many ways, I think the fact that it's > not marked iterable is a peculiar detail to get stuck on. > > Regards, > -- > Rowan Collins > [IMSoP] >
-- -- Chase chasepeeler@gmail.com

Craig Duncan (PHP)

7 years ago
The RFC has failed with 7 votes in favour and 25 against. Thanks again to everybody that got involved and voiced their opinions