ForIn/OfHeadEvaluation invokes EnumerateObjectProperties and returns its result.
But EnumerateObjectProperties returns an iterator object and ForIn/OfHeadEvaluation should be returning an iterator record (since aa163479, see issue #988 from @kmiller68).
So either:
ForIn/OfHeadEvaluation should be altered to construct an iterator record from the iterator object that EnumerateObjectProperties returns, or EnumerateObjectProperties should be altered to return an iterator record.(I think.)
I'd prefer the former, to avoid complicating the spec steps for Object.{keys,values,entries}.
Whoops I missed this. Good catch @jmdyck! I agree with @ljharb the former seems like the better solution. I'm happy to make the change unless someone else is interested or objects.
I'd prefer the former, to avoid complicating the spec steps for
Object.{keys,values,entries}.
I don't understand why changing EnumerateObjectProperties to return an iterator record would cause the spec steps for Object.{keys,values,entries} to change. They invoke EnumerableOwnProperties, which refers to EnumerateObjectProperties, but doesn't even invoke it, really. It seems like EnumerableOwnProperties could handle the change just by replacing the Iterator with the iterator record (in the Iterator that would be returned if the EnumerateObjectProperties internal method were invoked with _O_).
I was thinking that it would be better to change ForIn/OfHeadEvaluation rather than EnumerableObjectProperties as changing EnumerableObjectProperties would mean that the example below needs to be changed. I'm mostly indifferent though.
EnumerableOwnProperties doesn't have an example. I think you mean EnumerateObjectProperties.
Yeah, I copy pasted wrong the wrong word... That's what I get for commenting past my bed time... of 9pm.
Okay, the sample code in EnumerateObjectProperties seems like a valid reason.
@kmiller68: Are you still happy to make the change?
It looks like PR #1969 fixed this.