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
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
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
--
--
regards / pozdrawiam,
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
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-stdclassNote 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.
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
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]
On Tue, Feb 5, 2019 at 1:46 PM Rowan Collins rowan.collins@gmail.com
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